Summary

Question

Customer Environment

Symptoms

• When connecting to an HTTPS interface the client software complains that the server certificate is invalid or that the connection is not secure.
  • What is meant by HTTPS interface? This can be a website hosted on a web server. This can also be an API interface. Any HTTPS interface that uses a TLS certificate to encrypt the communication. 
  • Example of a certificate that cannot be verified by Postman:

• Upon further inspection the certificate details on the client show:
  • Either there is no Root certificate that could be linked to the server certificate. 
  • Or there is a Root certificate that could be linked to the server certificate (explanation under "Resolution"). 
• When bypassing the certificate warning, the requested resource is available normally. 

Troubleshooting Steps

• If the client software supports a certificate details' view, look out for the following:
  • Is the certificate still valid? When does the validity end? 
  • What is the certificate's common name and more importantly: what are the certificate's subject alternative names (SAN)?
  • Was the HTTPS resource addressed by a name that is included in the subject alternative names? 
  • Are the subject alternative names resolvable addresses in the domain your client operates? (this may also include the Internet)
  • Can the client software link the certificate to a Root certificate (possibly with intermediate certificates in between)? 
  • Was the certificate signed by a public Certificate Authority or a private Certificate Authority? 
  • Or: is the certificate self-signed? 
• If you have a system with openssl at your disposal, you can also look up the certificate details by using this command:
  • openssl s_client -showcerts -connect www.example.com:443 | openssl x509 -noout -text 
  • Note the certificate's reported chain at the output's top. 
• Isolate the certificate's validity dates:
  • openssl s_client -showcerts  -connect www.example.com:443 | openssl x509 -noout -dates

Resolution

• In order for a client to verify a server certificate the following criteria need to be met:
  • The server certificate needs to have been signed by a Certificate Authority.
  • The client needs to have the relevant Root Certificate Authority it its certificate trust store. 
  • The HTTPS interface needs to be addressed by a name that is stored in the Common Name field (but more often in the Subject Alternative Name field). 
  • Wildcard certificates can use any subdomain name as long as it matches the domain name. 
  • The client needs to be able to close the certificate chain if there are intermediate Certificate Authorities involved between the Root Certificate Authority and the signed server certificate. A client can close the chain either if the intermediate certificates are stored in the client's certificate trust store or if the intermediate certificates are stored on the server that is being accessed. 
• 1st scenario: If your HTTPS interface uses a self-signed certificate the communication is going to be encrypted but a client is never going to be able to verify the certificate because there was no Certificate Authority involved in the signing process. That is because the client is unable to check the certificate against its certificate trust store. Typical self-signed certificate:

• Solution: In this case the problem can only be solved by replacing the self-signed certificate with a certificate signed by a Certificate Authority. 

• 2nd scenario: The HTTPS resource is being addressed by a name that the certificate does not have in either its Common Name field or Subject Alternative Name field. The address that is being used is reachable and resolvable by DNS.
  • Solution: The address being used needs to be included in the Subject Alternative Name field. The Subject Alternative Name field can include domain names as well as IP addresses. You can either have the certificate be signed again with an extended list of SANs or use a different address to access the HTTPS resource.
• 3rd scenario: The HTTPS interface uses a privately signed certificate that only clients within a certain domain know the Certificate Authority of. External clients that are trying to access the HTTPS interface are unable to verify the server certificate. 
  • Solution: Add all relevant CA certificates to the external client's certificate trust store. Please refer to your software's manual on how to add new certificates to the trust store (browser software, API clients, operating system trust stores, etc.). 
• 4th scenario: The client is unable to close a certificate chain because certain intermediate certificates are missing (The aforementioned openssl check reveals if there is a certificate chain present and how many levels deep it is). This problem will often manifest in a verified certification path that only shows the server certificate but no other CAs. 

• Solution: Missing intermediate certificates can either be added to the client's trust store or it can be appended to the server certificate. We are going to discuss appending the intermediate certificate to the server's certificate. That will leave the client with only having to know the root certificate in order to close the chain and verify the server certificate.
• If you have access to the server certificate's file and the file is in the PEM format, you can simply append the intermediate certificate (or multiple) underneath and save the file. The order in which the certificate blocks need to be arranged is: server certificate > intermediate certificate 1 > intermediate certificate 2 > root certificate (if applicable). 
• Where can you get the needed certificates? Public Certificate Authorities mostly offer their certificates as a download on the Internet. Here is an example from Sectigo https://sectigo.com/knowledge-base/detail/Sectigo-Intermediate-Certificates/kA01N000000rfBO 
• Example of how the 2 certificates connect in the file (excerpt):

• Important: the 2 certificates need to connect exactly as shown above. No additional or fewer lines breaks can be used otherwise it does not work. 

• Some server applications have a separate option to add intermediate certificates to the server. Ruckus's Cloudpath GUI is an example of that:

• As shown in the screenshot, you can upload a complete certificate chain, individual PEM certificates or additional intermediate certificates ("Additional Chain"). When navigating this menu please also make sure to always include the Private Key when uploading a new certificate.