Feature Request - SSL Certificate Validation.

[dormitionskete]

Problem part 1

When connecting to a remote server using SSL or TLS, some situations require us to import the SSL certificate into the Java cacert file, or we get a message such as:

javax.mail.MessagingException: Could not connect to SMTP host: MY.SMTP.SERVER, port: 465;
  nested 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

This page has very good explanation of it, and two different methods to deal with it.

https://confluence.atlassian.com/kb/connecting-to-ssl-services-802171215.html

We had this working fine, until we had to upgrade our SSL certificate. Now, no matter how or what we do to import the new certificate into Java's cacert file, or otherwise mark it as trusted, we have not been able to get it to work properly on our Macs to send mail using SimpleJavaMail. It works fine on our Linux thin client server, but not on either of the two Macs we have tried this procedure on.

I'm guessing it may have something to do with the fact that the Linux machine uses OpenJDK, whereas the Macs all use Oracle Java.

Problem part 2

Even if we could get it to work on the Macs, we have many Macs, all of which have different Java configurations. Further, even with portecle, it is a complex procedure to import these certificates. And this has to be done on every device we want to send mail through SimpleJavaMail.

Proposed Solution

Theoretically, we should be able to save the SSL key as a String in our application's database. Modify SimpleJavaMail to allow us to pass that key as a String as an optional parameter to the method that checks the SSL credentials that are throwing this error. If that String is empty, then ignore it and proceed checking the credentials as it is currently written. If that String is not empty, compare it with the key that gets pulled from the remote server. If they match, let it proceed.

This would allow us to get past this ValidatorException. It should completely eliminate the need to import that trusted certificate into each, or any machine. All we would have to do is to update the application's database with the new certificate information whenever it is renewed.

I'm willing to try to do the work on this; but if you think it would be useful for others, and would be willing to do this, you are much better at it than I am!

[bbottema]

Paging @cbarcenas. Do you have an opinion on this?

[bbottema]

@dormitionskete I have some reservation about this, because it means circumventing the internal mechanism for working with the trust store. Would the entire chain be represented by the String?

Also, I'm sceptical that working with certifications in Java is somehow broken on Apple computers. Seems to me certificates should be able to work on Macs or else there would be many more people having issues. Did you find anything else in your searches about this?

Alternatively you can choose to explicitely whitelist your mail server (not recommended, susceptible to man-in-the-middle attacks) using MailSender.trustHosts("yourhost") (note it currently contains a bug when supplying multiple hosts in a single call)

[dormitionskete]

I can certainly understand your reservations about this. I’m not sure that I would incorporate it into the library for the general public if I was in your position, either. I don’t think the entire certificate chain would be represented in the String. I think it would end up being only the trusted certificate itself. I’d have to look at what gets pulled from the Java security internal mechanism to know for sure. I’m not convinced this is a problem with all Apple computers, or necessarily with Oracle Java for Macs. I may just not have all of the parts of the chain updated in the cacerts file. I don’t know that much about this. We had an SSL “expert” here looking at this, and he couldn’t figure out what the problem was, either. Even though I don’t particularly like the idea of modifying your code to do this, I think I’m going to give it a try because it should still be a better solution than what we have been doing for the past three weeks or so to try to work around it. There are trade offs to everything. I appreciate your consideration of this, though. I wish you a very nice holiday season. Thank you again. On Dec 5, 2017, at 2:47 PM, Benny Bottema <notifications@github.com<mailto:notifications@github.com>> wrote: I have some reservation about this, because it means circumventing the internal mechanism for working with the trust store. Would the entire chain be represented by the String? Also, I'm sceptical that working with certifications in Java is somehow broken on Apple computers. Seems to me certificates should be able to work on Macs or else there would be many more people having issues. Did you find anything else in your searches about this? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#118 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ALHjMKcnUtJo4NrCBBn2DzsMX9iQrgjhks5s9bnZgaJpZM4QpkMB>.