Why does my client software complain about a TLS server certificate not being valid even though I know the correct certificate was uploaded to the server?


An explanation and set of instructions on how to fix an invalid TLS server certificate.


Why does my client software complain about a TLS server certificate not being valid even though I know the correct certificate was uploaded to the server?

Customer Environment

Cloudpath API accessed through Postman

Troubleshooting Steps

Perform the following steps to determine why the certificate is being marked as "invalid".
  • 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


In order to possibly solve the problem a few key points need to be explained:
  • 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:
User-added image
  • 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:
User-added image
  • 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. 

Article Number:

May 03, 2021 03:42 AM (almost 2 years ago)

Configuration, Security, Known Issues and Workarounds, Cloudpath, Unleashed, SmartCell Gateway


This article is:
not helpful

Working...Please wait

This is here to prevent you from accidentally submitting twice.

The page will automatically refresh.