|Applies To||RSA Certificate Manager 6.6|
|Issue||Error: "HTTPS Error Returned:: java.lang.Exception: no trusted certificates found" in RSA Certificate Manager|
Java application is using a .p7b file (PKCS#7) to load in their truststore do to a standard server authentication. That file contains the complete certificate chain and also the server certificate.
|Cause||The client application is architected improperly to store the server certificate and it's full certificate chain in the .p7b file. In this particular case, the issuer certificate (sub CA certificate) was resigned, so the serial number and md5 of the certificate is no longer the same. The SSL connection is then rejected.|
|Resolution||When doing a standard server certificate-based authentication, the client application should trust a CA certificate (preferably the Root CA), not the server certificate. For example, your web server has an SSL server certificate (SSLCert) issued by SubCA, whereas this SubCA is issued by RootCA. You must provide the full chain within your web server's configuration.|
Your client application needs to trust SubCA and/or RootCA ensuring that SSLCert will be chained to SubCA then trusted. In the symptom described above:
- The client application had SSLCert, SubCA, and RootCA in a single .p7b file, and the application was using this file as its truststore. The application was working fine.
- SubCA was then resigned (but not applied on the web server)
- The new SSLCert was exported with its full chain in a new .p7b file. This file then contained the new SubCA certificate.
- This new .p7b was then used by the application, and they had that symptom, because the application was doing a full certificate matching to allow the connection, and since SubCA certificate on the webserver was not the same as the one in the .p7b, the match failed, thus rejecting the connection.
|Workaround||The SSL server certificate was re-signed from the same CA, but that CA was previously re-signed|
|Legacy Article ID||a30733|