I'm trying to get an application running on top of Tomcat 6 to connect to an LDAP server over SSL.
I imported certificate of the server to keystore using:
C:\Program Files\Java\jdk1.6.0_32\jre\lib\security>keytool -importcert -trustcacerts -file mycert -alias ca_alias -keystore "c:\Program Files\Java\jdk1.6.0_32\jre\lib\security\cacerts"
When I start Tomcat with SSL debugging turned on, according to logs Tomcat is using the correct certificate file:
trustStore is: C:\Program Files\Java\jdk1.6.0_32\jre\lib\security\cacerts
However, Tomcat does not add the cert I just imported - all other certs in the cacerts file are printed to the log - and connection fails:
handling exception: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Restarting Tomcat does not help. I have verified with keytool -list command that the new cert indeed exists on the file.
Why Tomcat keeps on ignoring my new cert?
EDIT:
Seems that the issue was caused by Windows 7 VirtualStore. Keytool created a new copy of the cacert file, and Tomcat used the original file.
The problem is your Java is not trusting the certificate. You have to import it to your java's truststore . changeit is default truststore password. For every certificate that you imported into your truststore you have to provide a new alias.
JVM needs restart after importing certs to the keystore.
Check to see whether there is a key with the same CN information but a different alias.
I have had similar problems before when I tried to import a newer version of a certificate but left the older version in the keystore. My Java programs would simply find the first matching CN key in the keystore (which was the old expired one) and try to use that, even though there was a newer one which also matched the CN.
Also ensure that the authenticating Root certificate (and Intermediate certificate if applicable) exist in the keystore. If you're authenticating against one of the major security providers such as Verisign or Globalsign, they will usually provide you with the root and intermediate certificates. If these certificates exist in the keystore already, ensure they are still in validity. You need to have all the certificates from your personal certificate all the way down the authentication chain to the root, existing in your keystore, so that it understands how to validate your credentials.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With