Tips for verifying the SSL artifacts before using them in virtual hosts

phanim
New Member

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 Solved
0 1 470
1 ACCEPTED SOLUTION

phanim
New Member

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.

View solution in original post

1 REPLY 1

phanim
New Member

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.