UPDATE 1/26/2015 -- It appears the most recent JRE/JDK for Java 8 (update >= 31) and JRE/JDK for Java 7 now include the Godaddy G2 CA server in the default trust st
Mr. Fixer is right. Install the "GoDaddy G1 to G2 Cross" certificate in your certificate bundle file along with the intermediate certificate. This allows GoDaddy SHA-2 certificates to be trusted by any client that recognizes the SHA-1 roots including Java. You can get this file from https://certs.godaddy.com/repository Once this is installed, Java will build a certificate chain from your certificate to the "GoDaddy Secure Server Certificate (Intermediate Certificate)" to the "GoDaddy G1 to G2 Cross Certificate" to the GoDaddy SHA-1 root. You can also find a bundle file containing the cross certificate in our repository. One last note on this option: The signatures on root certificates aren't checked so even though you're relying on a SHA-1 root, this is just as secure as a full SHA-2 certificate chain.
It sounds like your mail server is not signed by Go Daddy Class 2 Certification Authority
, but is actually signed by one of their intermediate certificate authorities. You will need to verify this for yourself. Assuming this is the case...
In theory, your software should work - since the intermediate certificate is signed by the class 2 authority and you have the class 2 authority in the default JDK certificate store. However, I have found that it just does not work unless you also add the intermediate certificate to your certificate store. Here is a link to a blog post describing a similar experience:
http://drcs.ca/blog/adding-godaddy-intermediate-certificates-to-java-jdk/
Here is a direct link to more GoDaddy intermediate certificates: https://certs.godaddy.com/anonymous/repository.pki
I cannot advise on exactly which certificate you must add - it depends on which CA is used in your mail server.
[update]
is there a way to do this programmically?
Maybe. Depends on what you want to do. I have used the java.security.KeyStore
class to automatically update a private keystore directly from Java code without using keytool
. It is conceptually simple - load the keystore from a file, read the new certificate, add it to the keystore and then write out the keystore to new file. However it takes a while to get the details right and it may not be worth the trouble just to import a single certificate.
Still, it is interesting to try. Checkout KeyStore JavaDoc and read up on the load
, store
and setCertificateEntry
methods.
if you import de GoDady G2 bundle into the java keystore solves the problem:
export JAVA_HOME=/usr/lib/jvm/java-8-oracle/
wget https://certs.godaddy.com/repository/gd_bundle-g2.crt
$JAVA_HOME/bin/keytool -import -alias root -file ./gd_bundle-g2.crt -storepass changeit -trustcacerts -keystore $JAVA_HOME/jre/lib/security/cacerts
Mr. Fixer and Wayne Thayer's answers have been downvoted, but they are actually advocating the correct work-arounds. In fact, Wayne Thayer leads GoDaddy's SSL business, so he probably knows. You should install the "GoDaddy G1 to G2 Cross" certificate in your certificate chain along with the intermediate certificate.
Downgrading to SHA1 is not an ideal option since it's being deprecated and will cause you more work in the future. Fortunately, GoDaddy has provided a crossover certificate that solves this problem. They posted instructions, which Wayne has duplicated, and they're buried in the comments here.
I have personally tested this solution with a SHA2 cert, and it works well. It's a far superior solution vs. re-keying and downgrading to SHA1. When SHA2 becomes required, this option won't be available anyway, and there might still be Java toolchains out there without the new certificate.
According to GoDaddy support, as of July 2014, the correct root certificate was included in recent versions of Java 8, and in September 2014, Wayne Thayer of GoDaddy also said that the certificate "is scheduled to be added to Java in the next few months". I have checked the cacerts file in Java 8 for Mac OS downloaded from here, and it does indeed contain the SHA2 root certificate.
So instead of your chain looking like this:
It should look like this:
See also - my blog post summarizing this issue with work-arounds.
Following comments and the output of openssl s_client -connect the.server.name:587 -starttls smtp
.
In a certificate chain, cert n should be issued by cert n+1 in the list: the issuer (i) of cert n should be the subject (s) of cert n+1.
0 s:/OU=Domain Control Validated/CN=smtp.somecompany.com
i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
2 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
3 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
Here, cert 0 is issued by cert 1 (fine), cert 1 is issued by cert 2 (fine), cert 2 is self-signed (also fine, this is the root CA).
However, cert 2 isn't issued by cert 3. Cert 3 is misplaced (and probably the same as cert 1). This is likely to cause problems, since this makes the chain invalid.
You should at least remove cert 3 from your configuration. In addition, you can also remove cert 2, since having root CAs isn't necessary (it's up to the client to know it anyway).