I'm having a difficult time getting to the root of this issue. We use LDAP for authentication purposes across several services, confluence, bamboo, sonar, gerrit, etc.. Our LDAP service provider is Active Directory. I have all the services setup and working with LDAP and JDK 1.6.0_24. No authentication problems.
Recently we've tried to upgrade to the recent release of the JDK, 1.6.0_31. I repeat the same steps for the old JDK for importing LDAPs trusted cert from Active Directory:
Windows
Navigate to the directory in which Java is installed. It's probably called something like C:\Program Files\Java\jdk1.5.0_12.
Run the command below, where server-certificate.crt is the name of the file from your directory server:
keytool -import -keystore .\jre\lib\security\cacerts -file server-certificate.crt
keytool will prompt you for a password. The default keystore password is changeit.
When prompted Trust this certificate? [no]: enter yes to confirm the key import:
Enter keystore password: changeit
Owner: CN=ad01, C=US
Issuer: CN=ad01, C=US
Serial number: 15563d6677a4e9e4582d8a84be683f9
Valid from: Tue Aug 21 01:10:46 ACT 2007 until: Tue Aug 21 01:13:59 ACT 2012
Certificate fingerprints:
MD5: D6:56:F0:23:16:E3:62:2C:6F:8A:0A:37:30:A1:84:BE
SHA1: 73:73:4E:A6:A0:D1:4E:F4:F3:CD:CE:BE:96:80:35:D2:B4:7C:79:C1
Trust this certificate? [no]: yes
Certificate was added to keystore
Instructions from:
http://confluence.atlassian.com/display/DOC/Configuring+an+SSL+Connection+to+Active+Directory
I set the JAVA_HOME and PATH variables to the new JDK:
JAVA_HOME=C:\Program Files\Java\jdk1.6.0_31
PATH=%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\;c:\development\ant\bin;C:\development\tools\SysinternalsSuite;C:\Program Files\Java\jdk1.6.0_31\bin
When I start up any one of the existing services. My logs get loaded with LDAP authentication errors:
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
The same error for all services. Obviously something is going on with the path and the imported certificate. Using keytool I checked to make sure my LDAP cert imported properly, "mykey". It shows it successfully imported as a trusted cert:
C:\Program Files\Java\jdk1.6.0_31\jre\lib\security>keytool -list -keystore cac
ts
Enter keystore password:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 77 entries
digicertassuredidrootca, Jan 7, 2008, trustedCertEntry,
Certificate fingerprint (MD5): 87:CE:0B:7B:2A:0E:49:00:E1:58:71:9B:37:A8:93:72
trustcenterclass2caii, Jan 7, 2008, trustedCertEntry,
Certificate fingerprint (MD5): CE:78:33:5C:59:78:01:6E:18:EA:B9:36:A0:B9:2E:23
thawtepremiumserverca, Dec 2, 2009, trustedCertEntry,
Certificate fingerprint (MD5): A6:6B:60:90:23:9B:3F:2D:BB:98:6F:D6:A7:19:0D:46
swisssignplatinumg2ca, Aug 13, 2008, trustedCertEntry,
Certificate fingerprint (MD5): C9:98:27:77:28:1E:3D:0E:15:3C:84:00:B8:85:03:E6
swisssignsilverg2ca, Aug 13, 2008, trustedCertEntry,
Certificate fingerprint (MD5): E0:06:A1:C9:7D:CF:C9:FC:0D:C0:56:75:96:D8:62:13
thawteserverca, Dec 2, 2009, trustedCertEntry,
Certificate fingerprint (MD5): EE:FE:61:69:65:6E:F8:9C:C6:2A:F4:D7:2B:63:EF:A2
equifaxsecureebusinessca1, Jul 18, 2003, trustedCertEntry,
Certificate fingerprint (MD5): 64:9C:EF:2E:44:FC:C6:8F:52:07:D0:51:73:8F:CB:3D
utnuserfirstclientauthemailca, May 2, 2006, trustedCertEntry,
Certificate fingerprint (MD5): D7:34:3D:EF:1D:27:09:28:E1:31:02:5B:13:2B:DD:F7
thawtepersonalfreemailca, Dec 2, 2009, trustedCertEntry,
Certificate fingerprint (MD5): 53:4B:1D:17:58:58:1A:30:A1:90:F8:6E:5C:F2:CF:65
entrustevca, Apr 28, 2009, trustedCertEntry,
Certificate fingerprint (MD5): D6:A5:C3:ED:5D:DD:3E:00:C1:3D:87:92:1F:1D:3F:E4
utnuserfirsthardwareca, May 2, 2006, trustedCertEntry,
Certificate fingerprint (MD5): 4C:56:41:E5:0D:BB:2B:E8:CA:A3:ED:18:08:AD:43:39
certumca, Feb 10, 2009, trustedCertEntry,
Certificate fingerprint (MD5): 2C:8F:9F:66:1D:18:90:B1:47:26:9D:8E:86:82:8C:A9
entrustrootcag2, Jun 22, 2010, trustedCertEntry,
Certificate fingerprint (MD5): 4B:E2:C9:91:96:65:0C:F4:0E:5A:93:92:A0:0A:FE:B2
addtrustclass1ca, May 2, 2006, trustedCertEntry,
Certificate fingerprint (MD5): 1E:42:95:02:33:92:6B:B9:5F:C0:7F:DA:D6:B2:4B:FC
equifaxsecureca, Jul 18, 2003, trustedCertEntry,
Certificate fingerprint (MD5): 67:CB:9D:C0:13:24:8A:82:9B:B2:17:1E:D1:1B:EC:D4
quovadisrootca3, Jun 9, 2009, trustedCertEntry,
Certificate fingerprint (MD5): 31:85:3C:62:94:97:63:B9:AA:FD:89:4E:AF:6F:E0:CF
quovadisrootca2, Jun 9, 2009, trustedCertEntry,
Certificate fingerprint (MD5): XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
mykey, Apr 25, 2012, trustedCertEntry,
...
Did something change in the latest 1.6 JDK to break the default cert validation? How does this process work for the 24 release and yet fail for 31?
Any help is greatly appreciated. Thanks!
