Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Imported certificate to Java keystore, JVM ignores the new cert

Tags:

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.

like image 785
tputkonen Avatar asked May 07 '12 14:05

tputkonen


People also ask

How do I fix certificate errors in Java?

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.


2 Answers

JVM needs restart after importing certs to the keystore.

like image 86
SSLKida Avatar answered Oct 07 '22 20:10

SSLKida


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.

like image 36
wattostudios Avatar answered Oct 07 '22 20:10

wattostudios