GoDaddy SSL证书不使用Java [英] GoDaddy SSL Cert Not Working With Java
问题描述
更新2015年1月26日 - Java 8的最新JRE / JDK（更新> = 31）和Java 7的JRE / JDK现在包含Godaddy G2 CA服务器默认信任库。如果可能，请求您将JRE / JDK升级到最新的Java 8更新以解决此问题。
更新11/29/2014 - 这仍然是一个问题，Godaddy似乎不关心也不会做任何事情。有一篇博客文章这里 如果您愿意打电话，这是他们的SSL团队的联系信息： 更新2014年9月17日 - 这仍然是一个问题，Godaddy似乎不关心也不会做任何事情。 11月谷歌弃用所有SHA-1证书时，这将成为一个主要问题。我强烈推荐任何可以联系Godaddy并在此处指出的人。 〜
用户似乎应避免购买Godaddy SSL证书，直到他们认真对待CA.
GoDaddy SSL团队支持号码：1-480-505-8852 - 电子邮件：ra@godaddy.com
TL;博士; - 最后更新当前解决方案/解决方法在这篇文章的底部（这是一个GoDaddy问题，并且有一个解决方法，直到他们修复它）
<我有一个邮件服务器，我正试图从我的Java应用程序发送邮件。我可以成功发送端口25所以我知道代码工作和所有，但25不是加密会话。我需要在端口587上使用TLS，这需要SSL证书。我在GoDaddy G2 CA签署的服务器上有一个有效的SSL证书，并且已经存在了一段时间（没问题）。
我的问题是，我得到了着名的 PKIX路径构建失败：sun.security.provider.certpath.SunCertPathBuilderException：无法找到有效尝试在587上连接和发送邮件时，请求目标的证书路径错误消息。
从我对许多SO链接的理解以及正常情况google-fu，这通常是在Java不信任证书或CA时引起的 - 这对于自签名证书来说很常见。我已经使用了几个在线SSL证书检查器来确保链是有效的等等。所有似乎都是正常的...但是java不会自动使用证书。
我知道Sun的某个类文件将在本地密钥库中下载并设置cert，因此java会信任它...但这不仅仅是对于将部署到多个系统的应用程序来说是不切实际的，但对Godaddy签署的证书来说却是愚蠢的。
发生了什么事？如何让java使用服务器上的有效证书，而不必让java接受所有证书？
编辑：我只是查看了我的Windows Java控制面板（默认安装jdk 7），当然，在 Signer CA 下发布者： Go Daddy Group，Inc。Go Daddy列出了2级证书颁发机构 ...那么给出了什么？我的证书是Godaddy证书...
更新 -
这是从评论中推荐的openssl命令看到的证书链：
〜] #openssl s_client -connect smtp.somecompany.com:587 -starttls SMTP
相连接（00000003）
深度= 2 C = US，ST =亚利桑那，L =斯科茨，O = GoDaddy.com公司，CN =去爸爸根证书颁发机构 - G2
验证错误：num = 19：证书链中的自签名证书
验证退货：0
---
证书链
0 s：/ OU =域控制验证/ CN = smtp.somecompany.com
i：/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com,Inc./OU=http://certs .godaddy.com / repository // CN = Go Daddy安全认证机构 - G2
1 s：/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com,Inc./OU=http： //certs.godaddy.com/repository//CN=Go爸爸安全证书颁发机构 - G2
i：/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com,Inc./CN=Go爸爸根证书颁发机构 - G2
2 s：/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com,Inc/CN=Go爸爸根证书颁发机构 - G2
i：/ C = US / ST = Arizona / L = Scottsdale /O=GoDaddy.com,Inc/CN=Go爸爸根证书颁发机构 - G2
3 s：/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com,Inc./OU= http://certs.godaddy.com/repository//CN=Go爸爸安全证书颁发机构 - G2
i：/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com,Inc./CN =去爸爸根证书颁发机构 - G2
---
我认为对我好...
更新2 -
好的，感谢@Bruno我能够确定我的链条搞砸了 - 我重新键入了服务器，现在我的链条显示为：
〜]＃的OpenSSL的s_client.First -connect smtp.somecompany.com:587 -starttls SMTP
相连接（00000003）
深度= 2 C = US，ST =亚利桑那，L = Scottsdale的O =GoDaddy.com，Inc。，CN = Go Daddy Root Certificate Authority - G2
验证错误：num = 19：自签名证书证书链中的e
验证返回：0
---
证书链
0 s：/ OU =域控制验证/ CN = smtp.somecompany.com
i ：/ C = US / ST = Arizona / L = Scottsdale / O = GoDaddy.com，Inc。/ OU = http：//certs.godaddy.com/repository//CN=Go爸爸安全证书颁发机构 - G2
1 s：/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com,Inc ./OU=http://certs.godaddy.com/repository//CN=Go爸爸安全证书颁发机构 - G2
i：/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com,Inc/CN=Go爸爸根证书颁发机构 - 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
---
哪个看起来比之前。 - Java仍然会抛出有关证书路径等的相同异常。因此，在Java 7的默认密钥库中，似乎默认情况下不会信任G2证书链。
2014年1月14日的完整性最终更新
就像更新一样 - 这确实是一个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 服务器添加到默认信任库之前的解决方法是使用 SHA-1 as-to获得由 Class 2 CA 服务器签名的证书。 GoDaddy客户可以免费重新加密，直到您的证书到期（显然）。
更新1/26 / 2015年 - Java 8的最新JRE / JDK（更新> = 31）和Java 7的JRE / JDK现在包括默认信任库中的Godaddy G2 CA服务器。如果可能，请求您将JRE / JDK升级到最新的Java 8更新以解决此问题。
更新11/29/2014 - 这仍然是一个问题，Godaddy似乎不关心也不会做任何事情。几个月前Godaddy的安全产品副总裁有一篇博客文章 [here] [1] 说修复工作正在进行并提供临时解决方案，但是因为今天一切都没有改变。值得注意的是Godaddy的G2 CA服务器已经存在了至少5年，并且在那段时间Godaddy没有采取适当的步骤来解决这个已知问题。所提供的解决方案就是解决方案，而不是解决方案。第三方服务的用户无法控制服务器上的证书安装方式。
用户似乎应避免购买Godaddy SSL证书，直到他们认真对待CA.
如果您愿意打电话，这是他们的SSL团队的联系信息：
GoDaddy SSL团队支持号码：1-480-505-8852 - 电子邮件：ra@godaddy.com
更新2014年9月17日 - 这仍然是一个问题，Godaddy似乎不关心也不会做任何事情。 11月谷歌弃用所有SHA-1证书时，这将成为一个主要问题。我强烈推荐任何可以联系Godaddy并在此处指出的人。
~~~~
我的帖子/问题是为什么我的连锁店不起作用。很明显我的设置很糟糕（很快就通过@Bruno和其他人的一些建议来修复 - 谢谢）。然而，当我的纠正链仍然无法使用Java时，很明显潜伏着更大的问题。花了一段时间，但问题实际上是GoDaddy。
这实际上确实是一个GoDaddy问题（我有很长时间的支持电子邮件）。
他们有2台CA服务器，一台名为 Class 2 CA ，另一台名为 G2 CA 。他们的 Class 2 CA 签署所有 SHA-1 证书，而 G2 CA 签署所有 SHA-2 证书。
这就是问题所在 - GoDaddy尚未将新的 G2 CA 服务器添加到默认 Java truststore / keystore - 导致默认Java安装不信任它的权限，因此不信任您的链式证书。
GoDaddy将 G2 CA 服务器添加到默认信任库/密钥库之前的解决方法是简单地重新生成密钥使用 SHA-1 的证书，以获得由 Class 2 CA 服务器签署的证书。 GoDaddy客户可以免费重新加密，直到您的证书到期（显然）。
一旦你有 SHA-1 证书由 Class 2 CA 服务器签名，您的信任链应按预期工作，并且不需要自定义信任库/密钥库导入和/或设置。
为了让它正常工作，我必须使用弱证书才能让我高兴，到目前为止，通过电子邮件支持与GoDaddy进行的讨论已经表明他们目前没有计划将 G2 CA 服务器添加到默认的truststore / keystore。我想直到他们确实添加它，确保你获得 SHA-1 Class 2 CA 服务器签名证书如果你计划使用Java。
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 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.
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:
GoDaddy SSL Team Support Number: 1-480-505-8852 -- Email: ra@godaddy.com
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.
~
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).
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 target error message when trying to connect and send mail on 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.
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.
What's going on? How can I make java use the valid cert on the server without having to make java accept all certs?
EDIT: I just looked in my windows Java Control Panel (default install of jdk 7) and sure enough, under Signer CA the Issued By: The Go Daddy Group, Inc. Go Daddy Class 2 Certification Authority is listed... so what gives? My cert is a Godaddy cert...
UPDATE --
Here's the cert chain as-seen from openssl command recommended in 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
---
Looks ok to me I think...
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:
~]# 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.
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 CA and the other called G2 CA. Their Class 2 CA signs all SHA-1 certificates, while the G2 CA signs all their SHA-2 certificates. This is where the problem lies - GoDaddy has not added their newer G2 CA server 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 CA server to the default truststore is to simply rekey your cert using SHA-1 as-to get a cert signed by the Class 2 CA server. Rekeying is free for GoDaddy customers until your cert expires (obviously).
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.
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:
GoDaddy SSL Team Support Number: 1-480-505-8852 -- Email: ra@godaddy.com
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.
~~~~
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.
This actually is indeed a GoDaddy problem (I've had lengthy support emails with them).
They have 2 CA servers, one called Class 2 CA and the other called G2 CA. Their Class 2 CA signs all SHA-1 certificates, while the G2 CA signs all their SHA-2 certificates.
This is where the problem lies - GoDaddy has not added their newer G2 CA server to the default Java truststore/keystore - 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 CA server to the default truststore/keystore is to simply rekey your cert using SHA-1 as-to get a cert signed by the Class 2 CA server. Rekeying is free for GoDaddy customers until your cert expires (obviously).
Once you have a SHA-1 cert signed by the Class 2 CA server, your trust chain should work as expected and no custom truststore/keystore imports and/or setup is required.
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 CA server to the default truststore/keystore. I guess until they do add it, make sure you get a SHA-1 Class 2 CA server signed cert if you plan to work with Java.
这篇关于GoDaddy SSL证书不使用Java的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
