For secure communication with API proxies (or) with Target server we need to perform the following actions
1. Create keystore or truststore (truststore if 2-way SSL is required) on the Edge
2. Properly create the SSL files and validate them. This includes key file, certificate and CA chain
3. Upload these files onto the keystore or truststore
4. Create keystore or truststore references
5. Use these references for north-bound or south-bound connections
What are TIPs and best practices that help to validate the SSL artifacts?
Solved! Go to Solution.
Sometimes, apigee support is approached with SSL files which may not have been properly created (or) provided in right format. Note that SSL files have to be in proper format to create virtual hosts for north-bound connections and for the south-bound as well. If there is a slight discrepancy, it will lead to errors being thrown at routers (or) target side connections while establishing secure communication.
Here are some of the TIPs and commands that can help to sanity check the SSL key file, certificate and CA chain.
1. First convert the SSL files into PEM format. This link provides more information about the keystores & trustores. Visit this link for knowing more about how to convert SSL files into various formats.
2. Check the CA or SAN fields in the certificate using the below command.
openssl x509 -in <certificate_file> -text
The value of CA or SAN field should match the host alias being used in the virtual host.
3. Check the modulus of the key & certificate using the below commands
openssl rsa -noout -modulus -in <key_file> | openssl md5 openssl x509 -noout -modulus -in <certificate_file> | openssl md5
The output from both the commands should be same.
4. Check the validity of the entire certificate chain by calculating the hash sequence of each intermediate certificate as illustrated below.
$ openssl x509 -in <top_level_certificate> -hash -issuer_hash -noout 22901147 8d28ae65 $ openssl x509 -in <next_intermediate_CA cert> -hash -issuer_hash -noout 8d28ae65 d6325660 $ openssl x509 -in <next_intermediate_CA cert> -hash -issuer_hash -noout d6325660 157753a5 $ openssl x509 -in <root_certificate> -hash -issuer_hash -noout 157753a5 157753a5
Observe that the output from the each command above prints hash sequence of the certificate used in the command, and the hash sequence of its issuer certificate. So, the hash sequence of the issuer should be same as the hash sequence of the next certificate in the certificate chain. You can calculate and verify the hash sequences as described above upto the root certificate. The hash sequence of the root certificate and its issuer are same.
5. After checking the above, upload the SSL files into the respective keystore using Egde UI. Uploading the SSL files using the Edge UI is easier.
6. Create references for the keystore (or) truststore and use these references in the virtual host. This helps to easily update the certificate when it expires without needing to restart the routers. For more information about the references visit this link.
Sometimes, apigee support is approached with SSL files which may not have been properly created (or) provided in right format. Note that SSL files have to be in proper format to create virtual hosts for north-bound connections and for the south-bound as well. If there is a slight discrepancy, it will lead to errors being thrown at routers (or) target side connections while establishing secure communication.
Here are some of the TIPs and commands that can help to sanity check the SSL key file, certificate and CA chain.
1. First convert the SSL files into PEM format. This link provides more information about the keystores & trustores. Visit this link for knowing more about how to convert SSL files into various formats.
2. Check the CA or SAN fields in the certificate using the below command.
openssl x509 -in <certificate_file> -text
The value of CA or SAN field should match the host alias being used in the virtual host.
3. Check the modulus of the key & certificate using the below commands
openssl rsa -noout -modulus -in <key_file> | openssl md5 openssl x509 -noout -modulus -in <certificate_file> | openssl md5
The output from both the commands should be same.
4. Check the validity of the entire certificate chain by calculating the hash sequence of each intermediate certificate as illustrated below.
$ openssl x509 -in <top_level_certificate> -hash -issuer_hash -noout 22901147 8d28ae65 $ openssl x509 -in <next_intermediate_CA cert> -hash -issuer_hash -noout 8d28ae65 d6325660 $ openssl x509 -in <next_intermediate_CA cert> -hash -issuer_hash -noout d6325660 157753a5 $ openssl x509 -in <root_certificate> -hash -issuer_hash -noout 157753a5 157753a5
Observe that the output from the each command above prints hash sequence of the certificate used in the command, and the hash sequence of its issuer certificate. So, the hash sequence of the issuer should be same as the hash sequence of the next certificate in the certificate chain. You can calculate and verify the hash sequences as described above upto the root certificate. The hash sequence of the root certificate and its issuer are same.
5. After checking the above, upload the SSL files into the respective keystore using Egde UI. Uploading the SSL files using the Edge UI is easier.
6. Create references for the keystore (or) truststore and use these references in the virtual host. This helps to easily update the certificate when it expires without needing to restart the routers. For more information about the references visit this link.