Discussion:
cacerts keystore - Am I adding SSL certs to the right one?
f***@atlassian.com
2011-03-28 19:08:38 UTC
Permalink
Hello,

I am working on checking out an upgrade to 4.3 and am currently trying to work through an issue with connecting to our AD system using SSL.

I can connect just fine to AD through the new LDAP User Directories tool if I don't use SSL; however, this is discouraged in our intranet and I would rather use SSL.

The problem is, when I try to set it up and use the test connection button, I receive this error on the page:
{code}Connection test failed. Response from the server:
simple bind failed: my.ad.server.com:636; nested exception is javax.naming.CommunicationException: simple bind failed: my.ad.server.com:636
[Root exception is 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]{code}
This is the program I am using to try to add the certs to my test JIRA setup, running on my desktop:

http://blogs.sun.com/gc/entry/unable_to_find_valid_certification

And this is the path to the cacerts file I am adding the entry to:

*C:\Apps\atlassian\JIRA\JIRA4.3\jre\lib\security\cacerts*

When I run *keytool -list -v -keystore cacerts* on this file, it shows my newly entered certs just fine. Yet, when I go back and try the test connection again with SSL checked, I still get the error.

This is my jira.home property from the admin panel's System Info: *C:\Apps\atlassian\Application Data\JIRA4.3*

What am I doing wrong? Am I required to restart JIRA to get it to recognize the new certs in the keystore?

Thanks!
Jared
--
Post by farrishj - online at:
http://forums.atlassian.com/thread.jspa?forumID=46&threadID=52713
f***@atlassian.com
2011-03-28 20:25:01 UTC
Permalink
Oooh, we've been having "fun" with that too recently.

Do you run java with parameters like the below? Adding these to JAVA_OPTS fixed most of our SSL problems (although there is one more to fix). Obviously, swap settings to use your paths and passwords etc

-Djavax.net.ssl.trustStore=/etc/pki/jssecacerts
-Djavax.net.ssl.trustStorePassword=xyzyxzxyz
-Djavax.net.ssl.keyStore=/etc/pki/confluence.dev.co.uk.pfx
-Djavax.net.ssl.keyStorePassword=confluence
-Djavax.net.ssl.keyStoreType=PKCS12
--
Post by broughn2 - online at:
http://forums.atlassian.com/thread.jspa?forumID=46&threadID=52713
f***@atlassian.com
2011-03-28 21:02:13 UTC
Permalink
Is there any difference between jssecacerts and cacerts?

I see the two mentioned in a way that seems interchangeable, but the JIRA-bundled JRE does not have jssecacerts, only cacerts. Does jsse denote any meaning? The InstallCert class also outputs a jssecacerts file by default (I edited the output to overwrite the cacerts file in the lib/security folder).

Also, would I add those options to the setenv.bat file? I know I've done that before, but for the life of me I can't remember how I did it. I think it was for Eclipse, though. I'm running the bundled JRE with JIRA.
--
Post by farrishj - online at:
http://forums.atlassian.com/thread.jspa?forumID=46&threadID=52713
f***@atlassian.com
2011-03-29 08:31:56 UTC
Permalink
Post by f***@atlassian.com
Is there any difference between jssecacerts and cacerts?
There can be, but they are the same format, so you probably don't actually need to worry about them, as long as you know it's reading your cacerts
Post by f***@atlassian.com
I see the two mentioned in a way that seems interchangeable, but the JIRA-bundled JRE does not have jssecacerts, only cacerts. Does jsse denote any meaning? The InstallCert class also outputs a jssecacerts file by default (I edited the output to overwrite the cacerts file in the lib/security folder).
I have an excerpt from Sun docs in our local doc system that says:
{code}
When creating a TrustManager, Sun's JSSE implementation will first check for an alternate cacert file before falling back on the standard cacerts file, so that you can provide a JSSE-specific set of trusted root certificates separate from ones that might be present in cacerts for code signing purposes.

The search order for the locating the trust store is:
1) <java-home>/lib/security/jssecacerts, then
2) <java-home>/lib/security/cacerts
If the file jssecacerts exists, then cacerts is not consulted.

When following CAS instructions, adding a certificate to cacerts does
nothing if a jssecacerts file exists
{code}

In our case, we're deliberately telling Java to read the certs we specifically put there (there's a long dull explanation of why we do it this way, it works for us, but our install is, um, complicated)
Post by f***@atlassian.com
Also, would I add those options to the setenv.bat file? I know I've done that before, but for the life of me I can't remember how I did it. I think it was for Eclipse, though. I'm running the bundled JRE with JIRA.
Yes, you do. In setenv.bat, you should find

set JAVA_OPTS="-Dsomething -Dsomethingelse -Dmorestuff"

Just add to that line.
--
Post by broughn2 - online at:
http://forums.atlassian.com/thread.jspa?forumID=46&threadID=52713
f***@atlassian.com
2011-03-29 13:30:45 UTC
Permalink
I just noticed you've got trustStore and keyStore. On this particular install, on my desktop, I don't have it configured for https, but our live system is. So my thinking is, I would point the trustStore setting to our .keystore file, and the keyStore to jre/lib/security/cacerts.

Two questions:

# Will setting the trustStore option interfere with our https setup on the live system?
# For my desktop, can I just point them to the same jre/lib/security/cacerts file, or should I create a separate dummy keystore file for trustStore?
--
Post by farrishj - online at:
http://forums.atlassian.com/thread.jspa?forumID=46&threadID=52713
Loading...