GoDaddy SSL Cert does not work with Java

Question

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 store. If possible, it urged you upgrade your JRE/JDK to the latest Java 8 update to resolve this issue.

UPDATE 11/29/2014 - This is still a problem, and Godaddy does not seem to care and will do nothing about it. There is a blog from Godaddy VP of Security Products from a few months ago, saying that the fix was on it and provided temporary work, but today nothing has changed. It is important to note that the Godaddy G2 CA server has been around for about 5 years, and at that time Godaddy did not take the right steps to solve this known problem. A workaround is just a workaround, not a solution. Third-party service users have zero control over how the certificate is installed on the server.

It seems users should avoid purchasing Godaddy SSL certs until they get serious about being a CA.

Here is their contact information for the SSL command if you want to call:

GoDaddy SSL Team Support Number: 1-480-505-8852 -- Email: [e-mail]

UPDATE 9/17/2014 - This is still a problem, and Godaddy does not seem to care and will do nothing about it. Come back in November, when Google devalues ​​all SHA-1 certificates, this will become a serious problem. I highly recommend anyone who can contact Godaddy and list them here.

~

tl;dr; - final update with current solution/workaround at the bottom of this post (it is a GoDaddy problem and there is a workaround until they fix it)

I have a mail server from which I am trying to send mail through my Java application. I can successfully send port 25, so I know that the code works and that's it, but 25 is not an encrypted session. I need to use TLS on port 587, which requires an SSL certificate. I have a valid SSL certificate on a server that is signed by GoDaddy G2 CA and has been working for a long time (no problem).

My problem, I get the famous PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target error message PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target when trying to connect and send mail to 587.

From my understanding of many SO links, as well as the usual google-fu, this usually happens when Java does not trust the certificate or CA - as is usually the case with a self-signed certificate. I used several online SSL Cert certificates to make sure the chain is valid, etc. Everything looks fine ... but java will not use the certificate automatically.

I know that there is a class file somewhere from Sun that will download and install the certificate in the local keystore so that java trusts it ... but it is not only impractical for an application to be deployed on several systems, but it is just silly for a signed Godaddy certificate.

What's happening? How can I get java to use a valid certificate on the server without making java accept all certificates?

EDIT: I just looked through my Java Control Panel (standard jdk 7 installation) and, of course, in the Signer CA section the message is listed: The Go Daddy Group, Inc. Go Daddy Class 2 Certification Authority The Go Daddy Group, Inc. Go Daddy Class 2 Certification Authority ... so what? My certificate is Godaddy certificate ...

UPDATE --

Here the certificate chain, as seen from the openssl command, is recommended in the comments:

 ~]# openssl s_client -connect smtp.somecompany.com:587 -starttls smtp CONNECTED(00000003) depth=2 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", CN = Go Daddy Root Certificate Authority - G2 verify error:num=19:self signed certificate in certificate chain verify return:0 --- Certificate chain 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 --- 

Regards, I think ...

UPDATE 2 --

Well, thanks to @Bruno, I was able to determine that my chain was corrupted - I connected the server again, and now my chain looks like that:

  ~]# openssl s_client -connect smtp.somecompany.com:587 -starttls smtp CONNECTED(00000003) depth=2 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", CN = Go Daddy Root Certificate Authority - G2 verify error:num=19:self signed certificate in certificate chain verify return:0 --- Certificate chain 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 --- 

Which looks better than before. - Java still raises the same exception with respect to cert path, etc. So it looks like the default G2 certificate chain is not trusted in the default java 7 keystore.

FINAL UPDATE FOR COMPLETENESS @ 1/14/2014

Just like the update - this is really a GoDaddy problem (I had long letters of support with them). They have two CA servers, one of which is called Class 2 CA , and the other is G2 CA Their Class 2 CA signs all SHA-1 certificates, and G2 CA signs all its SHA-2 certificates. This is the problem - GoDaddy has not added its new G2 CA server to the default java trust store, which is why the default java settings do not trust it with authority and, therefore, do not trust your chain certificate. Workaround until GoDaddy adds the G2 CA server to the default trust store, simply asks for your certificate using SHA-1 as to get a certificate signed by the Class 2 CA server. Rekeying is free for GoDaddy customers until your certificate expires (obviously).

Answer 1

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 store. If possible, it urged you upgrade your JRE/JDK to the latest Java 8 update to resolve this issue.

UPDATE 11/29/2014 - This is still a problem, and Godaddy does not seem to care and will do nothing about it. A few months ago, Godaddy VP of Security Products posted a blog post [here][1] stating that the patch was on it and provided temporary work, but nothing has changed today. It is important to note that the Godaddy G2 CA server has been around for about 5 years, and at that time Godaddy did not take the right steps to solve this known problem. A workaround is just a workaround, not a solution. Third-party service users have zero control over how the certificate is installed on the server.

It seems users should avoid purchasing Godaddy SSL certs until they get serious about being a CA.

Here is their contact information for the SSL command if you want to call:

GoDaddy SSL Team Support Number: 1-480-505-8852 -- Email: [e-mail]

UPDATE 9/17/2014 - This is still a problem, and Godaddy does not seem to care and will do nothing about it. Come back in November, when Google devalues ​​all SHA-1 certificates, this will become a serious problem. I highly recommend anyone who can contact Godaddy and list them here.

~~~~

My original post / question was about why my network is down. It became apparent that I had a bad setup (which was quickly fixed with some tips from @Bruno and others - thanks). However, when my patched chain still didn't work with Java, it became obvious that there was a much bigger problem lurking. This took some time, but the problem is actually with GoDaddy.

This is actually a GoDaddy problem (I had long letters of support).

They have two CA servers, one of which is called Class 2 CA , and the other is G2 CA Their Class 2 CA signs all SHA-1 certificates, and G2 CA signs all its SHA-2 certificates.

Here's the problem: GoDaddy did not add its new G2 CA server to the standard Java truststore/keystore , as a result of which the default Java settings did not trust it and therefore did not trust your chained certificate.

Work until GoDaddy adds the G2 CA server to the default / default keystore, just reinstall your certificate using SHA-1 as to get the certificate signed by the Class 2 CA server. Rekeying is free for GoDaddy customers until your certificate expires (obviously).

Once you have the SHA-1 certificate signed by the Class 2 CA server, your trust chain should work as expected, and you do not need to import and / or configure the import / key store.

I don’t like that I have to use a “weaker” certificate to make it work correctly, and email discussions with GoDaddy have so far indicated that they have no current plans to add the G2 CA server to the default / key store . I think, until they add it, make sure you get the SHA-1 Class 2 CA certificate signed by the server if you plan to work with Java.

Answer 2

Mr. Fixer and Wayne Thayer responses have been suspended, but they are in fact advocating for the right workarounds. In fact, Wayne Thayer leads the GoDaddy SSL business, so he probably knows. You must install the “GoDaddy G1 to G2 Cross” certificate in the certificate chain along with the intermediate certificate.

Switching to SHA1 is not ideal because it is outdated and will make you work more in the future. Fortunately, GoDaddy has provided a crossover certificate that solves this problem. They posted instructions that Wayne duplicated, and they were buried in the comments here .

I personally tested this solution with an SHA2 certificate and it works well. This is a much better solution against redialing and downgrading to SHA1. When SHA2 becomes necessary, this option will not be available in any case, and there may still be Java toolchains without a new certificate.

According to GoDaddy support, since July 2014, the correct root certificate has been included in the latest versions of Java 8, and in September 2014 Wayne Thayer of GoDaddy also said that the certificate "is planned to be added to Java in the next few months." I checked the cacerts file in Java 8 for Mac OS downloaded here and it really contains the SHA2 root certificate.

So instead of your chain it looks 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 built into some systems (e.g. Chrome). SnakeDoc claims that "it is not embedded in Java, Windows CE, Microsoft Exchange, and other 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:

• Certification Authority Go Daddy Class 2: (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 an old root certificate 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-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 problem with common tasks.

Answer 3

To obtain Godaddy certificates for working in Java with SHA2, you will need to use your cross-certificate in your chain to associate the G2 root (SHA2) with the G1 root (SHA1) until Java decides to update its repository. Cross Certificate Kit can be downloaded here:

https://certs.godaddy.com/anonymous/repository.pki

GoDaddy Certificate Bundles - G2 Turns to G1 with Root

 [gd_bundle-g2-g1.crt][1] 

Answer 4

Mr. Fixer is right. Install the "GoDaddy G1 in G2 Cross" certificate in the certificate package file along with the intermediate certificate. This allows you to trust GoDaddy SHA-2 certificates to any client that recognizes SHA-1 roots, including Java. You can get this file from https://certs.godaddy.com/repository . After it is installed, Java will build the certificate chain from your certificate to “GoDaddy Secure Server Certificate (Intermediate Certificate)” on “GoDaddy G1 to G2 Cross Certificate” to the root of GoDaddy SHA-1. You can also find the package file containing the cross certificate in our repository. One final note on this option: Signatures on root certificates are not verified, so even if you rely on the SHA-1 root, it is as secure as the full SHA-2 certificate chain.

Answer 5

The following comments and the output of openssl s_client -connect the.server.name:587 -starttls smtp .

In the chain of certificates, certificate n must be issued by certificate n + 1 in the list: issuer (i) of certificate n must be the subject of certificate 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 certificate 1 (fine), certificate 1 is issued by certificate 2 (fine), cert 2 is self-signed (also excellent, this is the root CA).

However, certificate 2 is not issued by certificate 3. Certificate 3 is not applied (and probably matches certificate 1). This can cause problems, as this makes the chain invalid.

You should at least remove cert 3 from your configuration. In addition, you can also remove cert 2, since root CAs are not needed (this is the same as letting the client know about it).

Answer 6

It looks like your mail server is not signed by the Go Daddy Class 2 Certification Authority , but is actually signed by one of their intermediate certification authorities. You will need to verify this yourself. Assuming this is so ...

Theoretically, your software should work - since the intermediate certificate is signed with a class 2 authority, and you have class 2 authority in the default JDK certificate store. However, I found that it just does not work unless you also add the intermediate certificate to the 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 additional GoDaddy intermediate certificates: https://certs.godaddy.com/anonymous/repository.pki

I can’t specify exactly which certificate you should add - it depends on which CA is used on your mail server.

[update]

is there a way to do this programmically?

May be. Depends on what you want to do. I used the java.security.KeyStore class to automatically update my own keystore directly from Java code without using keytool . This is conceptually simple - download the keystore from the file, read the new certificate, add it to the keystore and then write the keystore to the new file. However, it takes some time to get the details, and maybe you should not worry only about importing a single certificate.

However, it is interesting to try. Checkout KeyStore JavaDoc and read the load , store and setCertificateEntry .

Answer 7

In “Java Control Panel,” I just added a GD root certificate to “Secure Site CA,” and I no longer have a certificate error when using Java. The certificate I added was: Go Daddy Class 2 Certification Authority Root Certificate - G2

Answer 8

if you import the GoDady G2 package into java repository, 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 

Answer 9

Update - this "solution" is no longer valid (see my above accepted answer) - keeping this answer because it did help alleviate the problem so long as the side-effects are tolerable.

Well, I might have found a workaround for my case.

 props.put("mail.smtp.ssl.trust", "smtp.somecompany.com"); 

I added this to my session and now it works. This is a workaround, not an imho fix, as I still don't know why my Godaddy SSL certificate is not trusted by default ... it's not a self-signed certificate.

Someone please feel free to call, as I really would like to understand this problem.

Answer 10

Here is what you can try. Add the GoDaddy root and intermediate certificates to the runtime trust manager. those. start if application.

static final line GD_CERT1 = // "----- BEGIN CERTIFICATE -----" "MIIE0DCCA7igAwIBAgIBBzANBgkqhkiG9w0BAQsFADCBgzELMAkGA1UEBhMCVVMx" + "EDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxGjAYBgNVBAoT" + "EUdvRGFkZHkuY29tLCBJbmMuMTEwLwYDVQQDEyhHbyBEYWRkeSBSb290IENlcnRp" + "ZmljYXRlIEF1dGhvcml0eSAtIEcyMB4XDTExMDUwMzA3MDAwMFoXDTMxMDUwMzA3" + "MDAwMFowgbQxCzAJBgNVBAYTAlVTMRAwDgYDVQQIEwdBcml6b25hMRMwEQYDVQQH" + "EwpTY290dHNkYWxlMRowGAYDVQQKExFHb0RhZGR5LmNvbSwgSW5jLjEtMCsGA1UE" + "CxMkaHR0cDovL2NlcnRzLmdvZGFkZHkuY29tL3JlcG9zaXRvcnkvMTMwMQYDVQQD" + " EypHbyBEYWRkeSBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5IC0gRzIwggEi "+" MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC54MsQ1K92vdSTYuswZLiBCGzD "+" BNliF44v / z5lz4 / OYuY8UhzaFkVLVat4a2ODYpDOD2lsmcgaFItMzEUz6ojcnqOv "+" K / 6AYZ15V8TPLvQ / MDxdR / yaFrzDN5ZBUY4RS1T4KL7QjL7wMDge87Am + GZHY23e "+" cSZHjzhHU9FGHbTj3ADqRay9vHHZqm8A29vNMDp5T19MR / gd71vCxJ1gO7GyQ5HY "+" pDNO6rPWJ0 + tJYqlxvTV0KaudAVkV4i1RFXULSo6Pvi4vekyCgKUZMQWOlDxSq7n "+" e TOvDCAHf + jfBDnCaQJsY1L6d8EbyHSHyLmTGFBUNUtpTrw700kuH9zB0lL7AgMB "+" AAGjggEaMIIBFjAPBgNVHRMBAf8EBTADAQH / MA4GA1UdDwEB / wQEAwIBBjAdBgNV "+" HQ4EFgQUQMK9J47MNIMwojPX + 2yz8LQsgM4wHwYDVR0jBBgwFoAUOpqFBxBnKLbv "+" 9r0FQW4gwZTaD94wNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8v "+" b2NzcC5nb2RhZGR5LmNvbS8wNQYDVR0fBC4wLDAqoCigJoYkaHR0cDovL2NybC5n "+" b2RhZGR5LmNvbS9nZHJvb3QtZzIuY3JsMEYGA1UdIAQ / MD0wOwYEVR0gADAzMDEG "+" CCsGAQUFBwIBFiVodHRwczovL2NlcnRzLmdvZGFkZHkuY29tL3JlcG9zaXRvcnkv "+" MA0GCSqGSIb3DQEBCwUAA4IBAQAIfmyTEMg4uJapkEv / oV9PBO9sPpyIBslQj6Zz "+" 91cxG7685C / B + LrTW + C05 + Z5Yg4MotdqY3MxtfWoSKQ7CC2iXZDXtHwlTxFWMMS2 "+" RJ17LJ3lXubvDGGqv + q¯qg + 6EnriDfcFDzkSnE3ANkR / 0yBOtg2DZ2HKocyQetawi "+" DsoXiWJYRBuriSUBAA / NxBti21G00w9RKpv0vHP8ds42pM3Z2Czqrpv1KrKQ0U11 "+" PIB / ikGQI31bS / 6kA1ibRrLDYGCD + H1QQc7CoZDDu + 8CL9IVVO5EFdkKrqeKM + 2 "+" LXY2JtwE65 / 3YR8V3Idv7kaWKK2hJn0KCacuBKONvPi8BDAB "; // + "----- END CERTIFICATE -----";

 static final String GD_CERT2 = //"-----BEGIN CERTIFICATE-----" "MIIEfTCCA2WgAwIBAgIDG+cVMA0GCSqGSIb3DQEBCwUAMGMxCzAJBgNVBAYTAlVT" +"MSEwHwYDVQQKExhUaGUgR28gRGFkZHkgR3JvdXAsIEluYy4xMTAvBgNVBAsTKEdv" +"IERhZGR5IENsYXNzIDIgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTQwMTAx" +"MDcwMDAwWhcNMzEwNTMwMDcwMDAwWjCBgzELMAkGA1UEBhMCVVMxEDAOBgNVBAgT" +"B0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxGjAYBgNVBAoTEUdvRGFkZHku" +"Y29tLCBJbmMuMTEwLwYDVQQDEyhHbyBEYWRkeSBSb290IENlcnRpZmljYXRlIEF1" +"dGhvcml0eSAtIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv3Fi" +"CPH6WTT3G8kYo/eASVjpIoMTpsUgQwE7hPHmhUmfJ+r2hBtOoLTbcJjHMgGxBT4H" +"Tu70+k8vWTAi56sZVmvigAf88xZ1gDlRe+X5NbZ0TqmNghPktj+pA4P6or6KFWp/" +"3gvDthkUBcrqw6gElDtGfDIN8wBmIsiNaW02jBEYt9OyHGC0OPoCjM7T3UYH3go+" +"6118yHz7sCtTpJJiaVElBWEaRIGMLKlDliPfrDqBmg4pxRyp6V0etp6eMAo5zvGI" +"gPtLXcwy7IViQyU0AlYnAZG0O3AqP26x6JyIAX2f1PnbU21gnb8s51iruF9G/M7E" +"GwM8CetJMVxpRrPgRwIDAQABo4IBFzCCARMwDwYDVR0TAQH/BAUwAwEB/zAOBgNV" +"HQ8BAf8EBAMCAQYwHQYDVR0OBBYEFDqahQcQZyi27/a9BUFuIMGU2g/eMB8GA1Ud" +"IwQYMBaAFNLEsNKR1EwRcbNhyz2h/t2oatTjMDQGCCsGAQUFBwEBBCgwJjAkBggr" +"BgEFBQcwAYYYaHR0cDovL29jc3AuZ29kYWRkeS5jb20vMDIGA1UdHwQrMCkwJ6Al" +"oCOGIWh0dHA6Ly9jcmwuZ29kYWRkeS5jb20vZ2Ryb290LmNybDBGBgNVHSAEPzA9" +"MDsGBFUdIAAwMzAxBggrBgEFBQcCARYlaHR0cHM6Ly9jZXJ0cy5nb2RhZGR5LmNv" +"bS9yZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEAWQtTvZKGEacke+1bMc8d" +"H2xwxbhuvk679r6XUOEwf7ooXGKUwuN+M/f7QnaF25UcjCJYdQkMiGVnOQoWCcWg" +"OJekxSOTP7QYpgEGRJHjp2kntFolfzq3Ms3dhP8qOCkzpN1nsoX+oYggHFCJyNwq" +"9kIDN0zmiN/VryTyscPfzLXs4Jlet0lUIDyUGAzHHFIYSaRt4bNYC8nY7NmuHDKO" +"KHAN4v6mF56ED71XcLNa6R+ghlO773z/aQvgSMO3kwvIClTErF0UZzdsyqUvMQg3" +"qm5vjLyb4lddJIGvl5echK1srDdMZvNhkREg5L4wn3qkKQmw4TRfZHcYQFHfjDCm" +"rw=="; //+"-----END CERTIFICATE-----"; static final String GD_CERT3 = //"-----BEGIN CERTIFICATE-----" "MIIEADCCAuigAwIBAgIBADANBgkqhkiG9w0BAQUFADBjMQswCQYDVQQGEwJVUzEh" +"MB8GA1UEChMYVGhlIEdvIERhZGR5IEdyb3VwLCBJbmMuMTEwLwYDVQQLEyhHbyBE" +"YWRkeSBDbGFzcyAyIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA0MDYyOTE3" +"MDYyMFoXDTM0MDYyOTE3MDYyMFowYzELMAkGA1UEBhMCVVMxITAfBgNVBAoTGFRo" +"ZSBHbyBEYWRkeSBHcm91cCwgSW5jLjExMC8GA1UECxMoR28gRGFkZHkgQ2xhc3Mg" +"MiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCASAwDQYJKoZIhvcNAQEBBQADggEN" +"ADCCAQgCggEBAN6d1+pXGEmhW+vXX0iG6r7d/+TvZxz0ZWizV3GgXne77ZtJ6XCA" +"PVYYYwhv2vLM0D9/AlQiVBDYsoHUwHU9S3/Hd8M+eKsaA7Ugay9qK7HFiH7Eux6w" +"wdhFJ2+qN1j3hybX2C32qRe3H3I2TqYXP2WYktsqbl2i/ojgC95/5Y0V4evLOtXi" +"EqITLdiOr18SPaAIBQi2XKVlOARFmR6jYGB0xUGlcmIbYsUfb18aQr4CUWWoriMY" +"avx4A6lNf4DD+qta/KFApMoZFv6yyO9ecw3ud72a9nmYvLEHZ6IVDd2gWMZEewo+" +"YihfukEHU1jPEX44dMX4/7VpkI+EdOqXG68CAQOjgcAwgb0wHQYDVR0OBBYEFNLE" +"sNKR1EwRcbNhyz2h/t2oatTjMIGNBgNVHSMEgYUwgYKAFNLEsNKR1EwRcbNhyz2h" +"/t2oatTjoWekZTBjMQswCQYDVQQGEwJVUzEhMB8GA1UEChMYVGhlIEdvIERhZGR5" +"IEdyb3VwLCBJbmMuMTEwLwYDVQQLEyhHbyBEYWRkeSBDbGFzcyAyIENlcnRpZmlj" +"YXRpb24gQXV0aG9yaXR5ggEAMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQAD" +"ggEBADJL87LKPpH8EsahB4yOd6AzBhRckB4Y9wimPQoZ+YeAEW5p5JYXMP80kWNy" +"OO7MHAGjHZQopDH2esRU1/blMVgDoszOYtuURXO1v0XJJLXVggKtI3lpjbi2Tc7P" +"TMozI+gciKqdi0FuFskg5YmezTvacPd+mSYgFFQlq25zheabIZ0KbIIOqPjCDPoQ" +"HmyW74cNxA9hi63ugyuV+I6ShHI56yDqg+2DzZduCLzrTia2cyvk0/ZM/iZx4mER" +"dEr/VxqHD3VILs9RaRegAhJhldXRQLIQTO7ErBBDpqWeCtWVYpoNz4iCxTIM5Cuf" +"ReYNnyicsbkqWletNw+vHX/bvZ8="; //+"-----END CERTIFICATE-----"; 

public static void main (String [] args) {

  TrustManagerFactory dtmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm()); dtmf.init((KeyStore) null); // gets you the default trust manager X509TrustManager defaultTm = null; for (TrustManager tm : dtmf.getTrustManagers()) { if (tm instanceof X509TrustManager) { defaultTm = (X509TrustManager) tm; break; } } CertificateFactory cf = CertificateFactory.getInstance("X.509"); byte [] decoded = Base64.getDecoder().decode(GD_CERT1); ByteArrayInputStream in = new ByteArrayInputStream(decoded); Certificate ca1 = cf.generateCertificate(in); in.close(); decoded = Base64.getDecoder().decode(GD_CERT2); in = new ByteArrayInputStream(decoded); Certificate ca2 = cf.generateCertificate(in); in.close(); decoded = Base64.getDecoder().decode(GD_CERT3); in = new ByteArrayInputStream(decoded); Certificate ca3 = cf.generateCertificate(in); in.close(); String keyStoreType = KeyStore.getDefaultType(); KeyStore ks = KeyStore.getInstance(keyStoreType); ks.load(null, null); ks.setCertificateEntry("cert1", ca1); ks.setCertificateEntry("cert2", ca2); ks.setCertificateEntry("cert3", ca3); TrustManagerFactory gdtmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm()); gdtmf.init(ks); X509TrustManager gdTm = null; for (TrustManager tm : gdtmf.getTrustManagers()) { if (tm instanceof X509TrustManager) { gdTm = (X509TrustManager) tm; break; } } TrustManager tms[] = new TrustManager[2]; tms[0] = gdTm; tms[1] = defaultTm; try { SSLContext sslCtx = SSLContext.getInstance("TLS"); sslCtx.init(null, tms, new SecureRandom()); } catch (java.security.GeneralSecurityException e) { e.printStackTrace(); throw e; } HttpsURLConnection.setDefaultSSLSocketFactory(sslCtx.getSocketFactory()); } 

. . .

Answer 11

, . . .

 props.put("mail.smtp.starttls.enable","true");