Hi El mar., 16 oct. 2018 a las 1:49, Igor Cicimov (<icici...@gmail.com>) escribió: > > Hi all, > > I just want to clarify something that I've been seeing behave differently > on various Java versions during the years. In case we have the following > setting: > > -Djavax.net.ssl.trustStore=/keystore/truststore.jks" > > in Tomcat's default config file, is JVM suppose to fall back to the global > CA store on the server under /etc/ssl/certs for verification in case *any* > of the certificates returned by a trusted domain are not present in the > above JKS store? By any I mean, all the certs in the chain returned by the > SSL handshake. > > For example, lets say we have a situation like this: > > DigiCert Global Root G2 -> RapidSSL TLS RSA CA G1 -> CN=*.mydomain.com > > Lets say I have imported the *CN=*.mydomain.com <http://mydomain.com>* > certificate in the truststore.jks, the question is is JVM going to look > under /etc/ssl/certs for RapidSSL in order to validate the CN signature and > then for DigiCert to validate the RapidSSL cert? > > As I said I had a mixed luck with this over the years, sometimes it works > as (I) expect it to work i.e. verify the certs by looking at the system CA > store and sometimes this is not the case.
My experience is that if you store a server certificate in the truststore.jks , don't search anyone more. This behaviour makes sense for me because you are saying that you trust in that certificate because you verified ( by other means ) it before Even if certificate is expired ( and server send it expired too, obviously ) , I think that is validated as trusted Regards > > Thanks for any help/insites. > > Igor --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
