GoDaddy SSL 证书不适用于 Java

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/18746565/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-08-12 10:42:25  来源:igfitidea点击:

GoDaddy SSL Cert Not Working With Java

javassljavamailzimbra

提问by SnakeDoc

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's urged you upgrade your JRE/JDK to the latest Java 8 update to resolve this issue.

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's 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 appears to not care nor will do anything about it. There is a blog post hereby Godaddy VP of Security Products from several months ago saying a fix was on it's way and provided a temporary work-around, but as-of today nothing has changed. It is important to note that Godaddy's G2 CA server has been around for a minimum of 5 years, and in that time Godaddy has not taken the proper steps to resolve this known issue. The work-around provided is just that, a work-around, not a solution. Users of 3rd party services have zero control over how the cert is installed on the server.

2014 年 11 月 29 日更新——这仍然是一个问题,Godaddy 似乎不在乎,也不会对此做任何事情。几个月前,Godaddy 安全产品副总裁在此处发表了一篇博客文章,称正在修复并提供临时解决方法,但截至今天,一切都没有改变。需要注意的是,Godaddy 的 G2 CA 服务器至少已经使用了 5 年,在此期间 Godaddy 还没有采取适当的步骤来解决这个已知问题。提供的变通方法只是一种变通方法,而不是解决方案。3rd 方服务的用户对证书在服务器上的安装方式具有零控制权。

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

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

Here is their SSL team's contact info if you feel inclined to call:

如果您想致电,以下是他们 SSL 团队的联系信息:

GoDaddy SSL Team Support Number: 1-480-505-8852 -- Email: [email protected]

GoDaddy SSL Team Support Number: 1-480-505-8852 -- Email: [email protected]

UPDATE 9/17/2014 -- This is still a problem, and Godaddy appears to not care nor will do anything about it. Come November when Google deprecates all SHA-1 certs, this will become a major issue. I highly recommend anyone who can contact Godaddy and point them here.

2014 年 9 月 17 日更新——这仍然是一个问题,Godaddy 似乎不在乎,也不会对此采取任何措施。到了 11 月,当 Google 弃用所有 SHA-1 证书时,这将成为一个主要问题。我强烈推荐任何可以联系 Godaddy 并将他们指向这里的人。

~

~

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)

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 that I'm attempting to send mail through from my Java app. I can sent on port 25 successfully so I know code works and all, but 25 is not encrypted session. I need to use TLS on port 587 which requires an SSL cert. I have a valid SSL Cert on the server that is signed by GoDaddy G2 CA and has been in place for a while now (no problems).

我有一个邮件服务器,我试图通过它从我的 Java 应用程序发送邮件。我可以在端口 25 上成功发送,所以我知道代码可以正常工作,但 25 不是加密会话。我需要在需要 SSL 证书的端口 587 上使用 TLS。我在服务器上有一个有效的 SSL 证书,该证书由 GoDaddy G2 CA 签名并且已经存在一段时间了(没问题)。

My issue, is I'm getting the famed PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested targeterror message when trying to connect and send mail on 587.

我的问题是,当我PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target尝试在 587 上连接和发送邮件时收到著名的错误消息。

From my understanding of many SO links as well as normal google-fu, this is usually caused when Java doesn't trust the cert or CA -- as is common for a self-signed cert. I've used several of the online SSL Cert checkers to make sure the chain is valid, etc. All appears to be normal... but java will not use the cert automatically.

根据我对许多 SO 链接以及普通 google-fu 的理解,这通常是在 Java 不信任证书或 CA 时引起的——这对于自签名证书来说很常见。我已经使用了几个在线 SSL 证书检查器来确保链是有效的,等等。一切似乎都很正常……但是 java 不会自动使用证书。

I am aware there is a class file somewhere from Sun that will download and setup the cert in the local keystore so java will trust it... but this is not only impractical for an app that will be deployed to multiple systems, but is just silly for a Godaddy signed cert.

我知道 Sun 某处有一个类文件,它将在本地密钥库中下载并设置证书,因此 Java 会信任它……但这对于将部署到多个系统的应用程序来说不仅不切实际,而且只是对于 Godaddy 签名的证书来说很傻。

What's going on? How can I make java use the valid cert on the server withouthaving to make java accept all certs?

这是怎么回事?如何让 java 使用服务器上的有效证书不必让 java 接受所有证书?

EDIT: I just looked in my windows Java Control Panel (default install of jdk 7) and sure enough, under Signer CAthe Issued By: The Go Daddy Group, Inc. Go Daddy Class 2 Certification Authorityis listed... so what gives? My cert is a Godaddy cert...

编辑:我刚刚查看了我的 Windows Java 控制面板(jdk 7 的默认安装),果然,在Signer CA发布者下:The Go Daddy Group, Inc. Go Daddy Class 2 Certification Authority列出了......那是什么?我的证书是 Godaddy 证书...

UPDATE --

UPDATE --

Here's the cert chain as-seen from openssl command recommended in comments:

以下是评论中推荐的 openssl 命令中的证书链:

~]# 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
---

Looks ok to me I think...

对我来说很好,我认为...

UPDATE 2 --

UPDATE 2 --

Ok, thanks to @Bruno I was able to determine my chain was messed up -- I re-keyed the server and now my chain appears as such:

好的,感谢@Bruno,我能够确定我的链条搞砸了——我重新键入了服务器,现在我的链条显示如下:

 ~]# 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 throws the same exception about the cert path, etc. So it appears that the G2 cert chain is not, by default, trusted yet in java 7's default keystore.

这看起来比以前好多了。-- Java 仍然会抛出关于证书路径等的相同异常。因此,默认情况下,Java 7 的默认密钥库中似乎不信任 G2 证书链。

FINAL UPDATE FOR COMPLETENESS @ 1/14/2014

FINAL UPDATE FOR COMPLETENESS @ 1/14/2014

Just as an update - This is indeed a GoDaddy problem (I've had lengthy support emails with them). They have 2 CA servers, one called Class 2 CAand the other called G2 CA. Their Class 2 CAsigns all SHA-1certificates, while the G2 CAsigns all their SHA-2certificates. This is where the problem lies - GoDaddy has not added their newer G2 CAserver to the default java truststore - causing default java installations to not trust it's authority, and hence, does not trust your chained certificate. The work-around until GoDaddy adds the G2 CAserver to the default truststore is to simply rekey your cert using SHA-1as-to get a cert signed by the Class 2 CAserver. Rekeying is free for GoDaddy customers until your cert expires (obviously).

就像更新一样 - 这确实是一个 GoDaddy 问题(我收到了很长的支持电子邮件)。他们有 2 个 CA 服务器,一个叫Class 2 CA,另一个叫G2 CA. 他们的Class 2 CA招牌所有SHA-1证书,而G2 CA招牌所有的SHA-2证书。这就是问题所在——GoDaddy 没有将他们的新G2 CA服务器添加到默认的 java 信任库——导致默认的 java 安装不信任它的权限,因此,不信任你的链式证书。在 GoDaddy 将G2 CA服务器添加到默认信任库之前的解决方法是简单地使用 as-重新加密您的证书SHA-1以获得Class 2 CA服务器签名的证书。在您的证书到期之前(显然),GoDaddy 客户可以免费重新生成密钥。

采纳答案by SnakeDoc

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's urged you upgrade your JRE/JDK to the latest Java 8 update to resolve this issue.

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's 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 appears to not care nor will do anything about it. There is a blog post[here][1]by Godaddy VP of Security Products from several months ago saying a fix was on it's way and provided a temporary work-around, but as-of today nothing has changed. It is important to note that Godaddy's G2 CA server has been around for a minimum of 5 years, and in that time Godaddy has not taken the proper steps to resolve this known issue. The work-around provided is just that, a work-around, not a solution. Users of 3rd party services have zero control over how the cert is installed on the server.

2014 年 11 月 29 日更新——这仍然是一个问题,Godaddy 似乎不在乎,也不会对此做任何事情。[here][1]几个月前,Godaddy 安全产品副总裁发表了一篇博客文章,称正在修复并提供临时解决方法,但截至今天,一切都没有改变。需要注意的是,Godaddy 的 G2 CA 服务器至少已经使用了 5 年,在此期间 Godaddy 还没有采取适当的步骤来解决这个已知问题。提供的变通方法只是一种变通方法,而不是解决方案。3rd 方服务的用户对证书在服务器上的安装方式具有零控制权。

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

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

Here is their SSL team's contact info if you feel inclined to call:

如果您想致电,以下是他们 SSL 团队的联系信息:

GoDaddy SSL Team Support Number: 1-480-505-8852 -- Email: [email protected]

GoDaddy SSL Team Support Number: 1-480-505-8852 -- Email: [email protected]

UPDATE 9/17/2014 -- This is still a problem, and Godaddy appears to not care nor will do anything about it. Come November when Google deprecates all SHA-1 certs, this will become a major issue. I highly recommend anyone who can contact Godaddy and point them here.

2014 年 9 月 17 日更新——这仍然是一个问题,Godaddy 似乎不在乎,也不会对此采取任何措施。到了 11 月,当 Google 弃用所有 SHA-1 证书时,这将成为一个主要问题。我强烈推荐任何可以联系 Godaddy 并将他们指向这里的人。

~~~~

~~~~

My initial post/question was regarding why my chain was not working. It became obvious I had a bad setup (which was quickly fixed with some advice from @Bruno and others - thanks). However, when my corrected chain still did not work with Java, it became apparent there was a much bigger problem lurking. It took a while, but the problem is actually with GoDaddy.

我最初的帖子/问题是关于为什么我的链条不起作用。很明显我的设置很糟糕(根据@Bruno 和其他人的一些建议很快解决了这个问题 - 谢谢)。然而,当我修正后的链仍然不能与 Java 一起工作时,很明显潜伏着一个更大的问题。花了一段时间,但问题实际上出在 GoDaddy 上。

This actually is indeed a GoDaddy problem (I've had lengthy support emails with them).

这实际上确实是一个 GoDaddy 问题(我收到了很长的支持电子邮件)。

They have 2 CA servers, one called Class 2 CAand the other called G2 CA. Their Class 2 CAsigns all SHA-1certificates, while the G2 CAsigns all their SHA-2certificates.

他们有 2 个 CA 服务器,一个叫Class 2 CA,另一个叫G2 CA. 他们的Class 2 CA招牌所有SHA-1证书,而G2 CA招牌所有的SHA-2证书。

This is where the problem lies - GoDaddy has not added their newer G2 CAserver to the default Java truststore/keystore- causing default Java installations to not trust it's authority, and hence, does not trust your chained certificate.

这就是问题所在——GoDaddy 尚未将其较新的G2 CA服务器添加到默认服务器中Java truststore/keystore——导致默认 Java 安装不信任其权限,因此不信任您的链式证书。

The work-around until GoDaddy adds the G2 CAserver to the default truststore/keystore is to simply rekey your cert using SHA-1as-to get a cert signed by the Class 2 CAserver. Rekeying is free for GoDaddy customers until your cert expires (obviously).

在 GoDaddy 将G2 CA服务器添加到默认信任库/密钥库之前的解决方法是简单地使用 as-重新加密您的证书SHA-1以获得Class 2 CA服务器签名的证书。在您的证书到期之前(显然),GoDaddy 客户可以免费重新生成密钥。

Once you have a SHA-1cert signed by the Class 2 CAserver, your trust chain should work as expected and no custom truststore/keystore imports and/or setup is required.

一旦您获得了服务器SHA-1签名的证书Class 2 CA,您的信任链应该会按预期工作,并且不需要自定义信任库/密钥库导入和/或设置。

It does not make me happy that I must use a "weaker" cert in order to get it to work properly, and discussions with GoDaddy via email support thus far have indicated they have no current plans to add the G2 CAserver to the default truststore/keystore. I guess until they do add it, make sure you get a SHA-1Class 2 CAserver signed cert if you plan to work with Java.

我必须使用“较弱”的证书才能使其正常工作,这让我很不高兴,到目前为止,通过电子邮件支持与 GoDaddy 的讨论表明,他们目前没有将G2 CA服务器添加到默认信任库/密钥库的计划. 我想在他们添加它之前,SHA-1Class 2 CA如果您打算使用 Java ,请确保您获得服务器签名的证书。

回答by SnakeDoc

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.

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.

Ok, I may have found a work-around for my case.

好的,我可能已经为我的案例找到了解决方法。

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

I added this to my Session construction, and now it works. This is a work-around, not a fix imho since I still do not know why my Godaddy SSL cert is not default trusted... it is not a self-signed cert.

我将此添加到我的会话构造中,现在它可以工作了。这是一种变通方法,而不是修复,恕我直言,因为我仍然不知道为什么我的 Godaddy SSL 证书不被默认信任......它不是自签名证书。

Anyone please feel free to chime in as I'd really like to understand this problem.

任何人都请随时加入,因为我真的很想了解这个问题。

回答by Guido Simone

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

听起来您的邮件服务器不是由 签名的Go Daddy Class 2 Certification Authority,但实际上是由其中一个中间证书颁发机构签名的。您需要亲自验证这一点。假设是这种情况......

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:

理论上,您的软件应该可以工作 - 因为中间证书是由 2 类授权机构签署的,并且您在默认的 JDK 证书存储中拥有 2 类授权。但是,我发现它不起作用,除非您还将中间证书添加到您的证书存储中。这是一篇描述类似经历的博客文章的链接:

http://drcs.ca/blog/adding-godaddy-intermediate-certificates-to-java-jdk/

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

以下是更多 GoDaddy 中间证书的直接链接: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.

我不能确切地建议您必须添加哪个证书 - 这取决于您的邮件服务器中使用的 CA。

[update]

[更新]

is there a way to do this programmically?

is there a way to do this programmically?

Maybe. Depends on what you want to do. I have used the java.security.KeyStoreclass 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.

也许。取决于你想做什么。我已经使用java.security.KeyStore该类直接从 Java 代码自动更新私有密钥库,而不使用keytool. 它在概念上很简单 - 从文件加载密钥库,读取新证书,将其添加到密钥库,然后将密钥库写出到新文件。但是,正确获取详细信息需要一段时间,并且仅导入单个证书可能不值得麻烦。

Still, it is interesting to try. Checkout KeyStore JavaDocand read up on the load, storeand setCertificateEntrymethods.

尽管如此,尝试还是很有趣的。签出KeyStore JavaDoc并阅读load,storesetCertificateEntry方法。

回答by Bruno

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

以下评论和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.

在证书链中,证书 n 应该由列表中的证书 n+1 颁发:证书 n 的颁发者 (i) 应该是证书 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).

这里,cert 0 由 cert 1 (fine) 颁发,cert 1 由 cert 2 (fine) 颁发,cert 2 是自签名的(也可以,这是根 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.

但是,证书 2 不是由证书 3 颁发的。证书 3 放错了位置(可能与证书 1 相同)。这很可能会导致问题,因为这会使链无效。

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

您至少应该从配置中删除 cert 3。此外,您还可以删除证书 2,因为不需要根 CA(无论如何都取决于客户端)。

回答by lanbrown

In the "Java Control Panel" I just added the GD Root Certificate to the "Secure Site CA" and I no longer have the cert error when using Java. The cert I added was: Go Daddy Class 2 Certification Authority Root Certificate - G2

在“Java 控制面板”中,我刚刚将 GD 根证书添加到“安全站点 CA”中,并且在使用 Java 时不再出现证书错误。我添加的证书是: Go Daddy Class 2 Certification Authority Root Certificate - G2

回答by Mr. Fixer

To get Godaddy certificates to work in Java with SHA2 you will need to use their cross certificate in your chain to chain the G2(SHA2) root to the G1(SHA1) root until Java decides to update their repository. The Cross Certificate bundle can be downloaded here:

要让 Godaddy 证书在 Java 中使用 SHA2,您需要在链中使用它们的交叉证书将 G2(SHA2) 根链接到 G1(SHA1) 根,直到 Java 决定更新其存储库。交叉证书包可以在这里下载:

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

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

GoDaddy Certificate Bundles - G2 With Cross to G1, includes Root

GoDaddy 证书捆绑包 - G2 与 G1 交叉,包括根

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

回答by Wayne Thayer

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/repositoryOnce 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.

Fixer 先生是对的。在您的证书包文件中安装“GoDaddy G1 到 G2 Cross”证书以及中间证书。这允许 GoDaddy SHA-2 证书被任何识别 SHA-1 根的客户端(包括 Java)信任。您可以从https://certs.godaddy.com/repository获取此文件安装后,Java 将构建从您的证书到“GoDaddy 安全服务器证书(中间证书)”到“GoDaddy G1 到 G2”的证书链交叉证书”到 GoDaddy SHA-1 根。您还可以在我们的存储库中找到包含交叉证书的捆绑文件。关于此选项的最后一个注意事项:即使您依赖 SHA-1 根,也不会检查根证书上的签名,

回答by Prathap BS

If u are using below properties while sending mail, then comment it. This works for me. But this might cause security problem.

如果您在发送邮件时使用以下属性,请对其进行评论。这对我有用。但这可能会导致安全问题。

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

回答by Isaac Potoczny-Jones

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.

Fixer 先生和 Wayne Thayer 先生的回答被否决了,但他们实际上是在提倡正确的变通方法。事实上,Wayne Thayer 领导着 GoDaddy 的 SSL 业务,所以他可能知道。您应该在证书链中安装“GoDaddy G1 to G2 Cross”证书以及中间证书。

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.

降级到 SHA1 不是一个理想的选择,因为它已被弃用,并且会导致您在未来做更多的工作。幸运的是,GoDaddy 提供了一个交叉证书来解决这个问题。他们张贴了 Wayne 复制的说明,并将它们隐藏在此处的评论中

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.

我已经使用 SHA2 证书亲自测试了此解决方案,并且效果很好。与重新加密和降级到 SHA1 相比,这是一个非常优越的解决方案。当需要 SHA2 时,此选项无论如何都将不可用,并且可能仍然存在没有新证书的 Java 工具链。

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

根据 GoDaddy 的支持,截至 2014 年 7 月,正确的根证书已包含在 Java 8 的最新版本中,而在 2014 年 9 月,GoDaddy 的 Wayne Thayer也表示该证书“计划在未来几个月内添加到 Java 中” ”。我已经检查了从这里下载的Java 8 for Mac OS 中的 cacerts 文件,它确实包含 SHA2 根证书。

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
  • Go Daddy Root 证书颁发机构 – G2:(SHA-2) – 哈希 47 BE AB C9 22 EA E8 0E 78 78 34 62 A7 9F 45 C2 54 FD E6 8B。这是某些系统(例如 Chrome)中内置的根证书。SnakeDoc 声称“它没有内置到 Java、Windows CE、Microsoft Exchange 和更多平台中”。
  • Go Daddy 安全证书颁发机构 – G2:(SHA-2) – 哈希 27 AC 93 69 FA F2 52 07 BB 26 27 CE FA CC BE 4E F9 C3 19 B8
  • 您的 SHA2 证书

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
  • Go Daddy Class 2 证书颁发机构:(SHA-1) – 哈希 27 96 BA E6 3F 18 01 E2 77 26 1B A0 D7 77 70 02 8F 20 EE E4。这是大多数系统(包括 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。这就是所谓的“GoDaddy G1到G2交叉证书” .
  • Go Daddy 安全证书颁发机构 – G2:(SHA-2) – 哈希 27 AC 93 69 FA F2 52 07 BB 26 27 CE FA CC BE 4E F9 C3 19 B8
  • 您的 SHA-2 证书

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

另请参阅 - 我的博客文章用变通方法总结了这个问题。

回答by jpereira

if you import de GoDady G2 bundle into the java keystore solves the problem:

如果您将 de GoDady G2 包导入 java 密钥库解决了问题:

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