GoDaddy SSL Cert Not Working With Java

前端 未结 11 1813
无人及你
无人及你 2020-12-22 22:55

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

相关标签:
11条回答
  • 2020-12-22 23:39

    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.

    0 讨论(0)
  • 2020-12-22 23:40

    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.

    0 讨论(0)
  • 2020-12-22 23:45

    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
    
    0 讨论(0)
  • 2020-12-22 23:46

    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:

    • Go Daddy Root Certificate Authority – G2: (SHA-2) – Hash 47 BE AB C9 22 EA E8 0E 78 78 34 62 A7 9F 45 C2 54 FD E6 8B. This is the root certificate that’s built into some systems (e.g. Chrome). SnakeDoc claims that "it's not built into Java, Windows CE, Microsoft Exchange, and more platforms".
    • Go Daddy Secure Certificate Authority – G2: (SHA-2) – Hash 27 AC 93 69 FA F2 52 07 BB 26 27 CE FA CC BE 4E F9 C3 19 B8
    • Your SHA2 certificate

    It should look like this:

    • Go Daddy Class 2 Certification Authority: (SHA-1) – Hash 27 96 BA E6 3F 18 01 E2 77 26 1B A0 D7 77 70 02 8F 20 EE E4. This is the old root certificate that’s built into most systems, including java.
    • Go Daddy Root Certificate Authority – G2: (SHA-2) – Hash 34 0B 28 80 F4 46 FC C0 4E 59 ED 33 F5 2B 3D 08 D6 24 29 64. This is the so-called “GoDaddy G1 to G2 Cross Certificate”.
    • Go Daddy Secure Certificate Authority – G2: (SHA-2) – Hash 27 AC 93 69 FA F2 52 07 BB 26 27 CE FA CC BE 4E F9 C3 19 B8
    • Your SHA-2 Certificate

    See also - my blog post summarizing this issue with work-arounds.

    0 讨论(0)
  • 2020-12-22 23:52

    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).

    0 讨论(0)
提交回复
热议问题