JIRA 5.0 Self Signed SSL Cert HostName mismatch

Question

Enabling SSL for LDAP -  the ldap cert has a CN=junk  (not dns resolvable).  I am getting a hostname mismatch when trying to enable SSL.  If I update all /etc/hosts to resolve "junk" to my ldap server - everything works perfectly.

LDAP admins cannot (willnot) change / update the cert to add Subjective Alternative Names's, nor fix the CN.

Is there a way in JIRA / Tomcat to bypass hostname validation for the LDAP connection?

Thanks!

FagnerF · Answer

Hi James,

It sounds the same issue type I got a few days ago, where I added the server name into the file /etc/hosts (in your case you added IP and name junk). Figuring out what was going on we found that at User Directories although we type 192.168.1.2 on hostname field we inserted the server's name ( as in your case junk) then it worked.

Just let you to know when you generated your self-signed certificated also its name goes together with the certified, but Jira doesn't translate DNS to "understand" whom is 192.168.1.2, that's why you should add some DNS informations into /etc/hosts to find who is junk to link its IP address.

Check out further informations on this link.

I really hope it can help you.

Cheers

James Saxton · Answer

Hey Eddie - Thanks for the input, had spent considerable time poking around for the bypass ssl cn name solution - I only see a code solution - am hoping for a http(s) conf bypass option.  I cannot agree with you enough regarding the security issue - and I have to document that -  I can advise and counsel - even speak from past experience - but in the end...

Thanks again!

EddieW_h8oivr · Answer

James, why not stick with the /etc/hosts fix?  That would allow a specific host (your ladp server) to be resolved by that url, and be trusted securely.

Without implementing a custom TrustManager  that trusts that particular host (or any host), there is no way to let Java SSL accept that connection. It is a major security concern as it allows any server to intercept your request and be trusted .

But if you want to go that route, http://stackoverflow.com/questions/2642777/trusting-all-certificates-using-httpclient-over-https