【问题标题】:GoDaddy SSL Cert Not Working With JavaGoDaddy SSL 证书不适用于 Java
【发布时间】:2013-09-15 19:04:49
【问题描述】:

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.

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

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

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

GoDaddy SSL Team Support Number: 1-480-505-8852 -- Email: ra@godaddy.com

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)

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

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

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

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

发生了什么事?如何让 java 使用服务器上的有效证书 而不必让 java 接受所有证书?

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

UPDATE --

这是 cmets 中推荐的从 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
---

在我看来还可以……

UPDATE 2 --

好的,感谢@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
---

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

FINAL UPDATE FOR COMPLETENESS @ 1/14/2014

作为一个更新 - 这确实是一个 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 重新加密您的证书,以获得由 Class 2 CA 服务器签名的证书。在您的证书到期之前(显然),GoDaddy 客户可以免费重新生成密钥。

【问题讨论】:

  • 你控制服务器吗?它的证书链是什么?您可以通过openssl -connect the.server.name:587 -starttls smtp 看到这一点。
  • 我确实控制着服务器,它就在我们的办公室里。它面向公众的电子邮件服务器 (zimbra)。由godaddy的G2 CA签名,使用链(链安装在服务器上,网上各种ssl验证工具都说链是有效的)。
  • @Bruno - 你的 openssl 命令对我不起作用。说没有命令-connect。我也试过 ssh...
  • 对不起,我的意思是openssl s_client -connect the.server.name:587 -starttls smtp
  • 作为更新 - 这确实是 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 简单地重新加密您的证书。

标签: java ssl jakarta-mail zimbra


【解决方案1】:

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.

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

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

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

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

【讨论】:

  • 据我所知,这会禁用该特定主机的证书验证,这不是一个好主意。
  • 对,这就是为什么我将其称为变通方法而不是解决方案的原因。在我的特殊情况下,它是我们办公室的服务器,但仍然容易受到中间人攻击,因为它始终信任服务器响应的任何证书......即使它已更改或错误。
【解决方案2】:

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

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

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

这里是更多 GoDaddy 中间证书的直接链接: https://certs.godaddy.com/anonymous/repository.pki

我无法确切说明您必须添加哪个证书 - 这取决于您的邮件服务器中使用的 CA。

[更新]

is there a way to do this programmically?

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

不过,尝试一下还是很有趣的。查看KeyStore JavaDoc 并阅读loadstoresetCertificateEntry 方法。

【讨论】:

  • +1 因为这似乎是潜在的罪魁祸首 - 它是由中间权威签署的,而不是主要的 2 类权威...... rats! - 你的链接发布在如何导入证书上似乎很好,但是有没有办法以编程方式做到这一点?我想避免将产品与证书文件一起发布并让一些脚本安装它们......有太多可能出错的变量,例如安装系统操作系统等......
  • 好的,我将接受这个作为答案,因为它比我下面的 hacky-work-around 更“正确”的解决方案。我的解决方法基本上忽略了密钥库并说“信任此服务器的证书”,至少从我的理解...使您的解决方案更加永久和优雅。
  • 仅供参考,这已被归档为JDK bug。另请注意,GoDaddy 已发布cross certificate from the G2 to the G1 root(邮件服务器使用的那个)。您应该能够下载“Go Daddy G1 到 G2 交叉证书”并配置邮件服务器证书链以将此证书包含在链的末尾。然后 JRE 将能够从 cacerts 文件中的 G2 根目录构建可信链。
【解决方案3】:

以下 cmets 和 openssl s_client -connect the.server.name:587 -starttls smtp 的输出。

在证书链中,证书 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

这里,cert 0 由 cert 1 颁发(罚款),cert 1 由 cert 2 颁发(罚款),cert 2 是自签名的(也可以,这是根 CA)。

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

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

【讨论】:

  • 您是如何配置邮件服务器的?我不确定 Zimbra 使用哪种配置(如果您使用的是这种配置)。
  • 我猜这个包已经包含了 g2 证书。无论如何,您实际上只需要 2 个证书:cert 0(您的证书)和 cert 1(中间 G2)。我会检查捆绑文件的内容。您可以将每个--BEGIN/END-- 部分输入openssl x509 -text -noout 以查看这些证书是什么。
  • 我很惊讶您需要重新生成 CSR。在再次通过 CA 流程之前,我会尝试使用现有证书重新配置。如果向导没有帮助,看起来有一些命令行工具:wiki.zimbra.com/wiki/… 我不太了解 Zimbra,但它看起来是基于 Java 的。如果您能找到它的密钥库在哪里,如果您找到了正确的别名(与 here 相同的方法),您也许可以使用 keytool 重新导入链。
  • 只是为了确保,您是否尝试使用keytool 将该根CA 导入您的security/cacerts 文件? (例如,如果您同时安装了 JDK 和独立 JRE,我会先复制原始文件,还要确保它是您的应用程序使用的文件)。
  • 我昨天基本上能够确认 G2 CA 不是默认受 Java 信任的 - 请参阅此 godaddy 链接:support.godaddy.com/groups/ssl-certificates/forum/topic/… - godaddy 已将其“2 类 CA”添加到默认信任库中,但是不是“G2 CA”。所以要点......它基本上不会在默认情况下工作,除非我手动设置密钥库以信任该程序将在每台部署的机器上运行的 CA......一个 PITA 恕我直言。
【解决方案4】:

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.

2014 年 11 月 29 日更新 -- 这仍然是一个问题,Godaddy 似乎并不关心,也不会对此采取任何措施。几个月前有一篇博文[here][1]by Godaddy 安全产品副总裁说正在修复它并提供了一个临时解决方法,但截至今天没有任何改变。需要注意的是,Godaddy 的 G2 CA 服务器已经存在了至少 5 年,在此期间 Godaddy 还没有采取适当的步骤来解决这个已知问题。提供的解决方法只是一种解决方法,而不是解决方案。 3rd 方服务的用户对如何在服务器上安装证书的控制为零。

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

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

GoDaddy SSL Team Support Number: 1-480-505-8852 -- Email: ra@godaddy.com

2014 年 9 月 17 日更新 -- 这仍然是一个问题,Godaddy 似乎不在乎,也不会对此采取任何措施。到了 11 月,当 Google 弃用所有 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 客户可以免费更新密钥。

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

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

【讨论】:

  • 当我们的 windows mobile 6.5 设备无法通过我们的 web 服务进行身份验证时,此解决方案对我有用。非常感谢您的帮助
  • 感谢您对此的研究和分享。在 Java 控制面板的“高级”选项卡上,有一个“在浏览器密钥库中使用证书和密钥”选项,因此它不应该根据 Java 密钥库检查证书(我认为)。但是当我使用谷歌浏览器时,我仍然遇到问题......
  • 我今天刚收到一封来自 GoDaddy 的电子邮件,说我应该将我的 ssl 证书重新设置为 SHA-2,以便它在 11 月之后继续与 Chrome 完美配合。但是,这样做时,它将使用 G2 CA 而不是 Class 2 CA,这将导致它在 Java 中失败。怎么办……怎么办?
  • 我看到了与@Brian2000 相同的消息。 GoDaddy 关于 Chrome 逐步淘汰 SHA-1 的完整详细信息如下:garage.godaddy.com/webpro/security/… 除非 GoDaddy 很快将其 G2 CA 服务器添加为默认的 Java 信任库/密钥库,否则我们可能会遇到麻烦。
  • 我个人认为人们需要关注 GoDaddy 并将他们链接到此页面。如果我是唯一一个引起他们注意的人,他们会像现在一样不理会它。
【解决方案5】:

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

【讨论】:

    【解决方案6】:

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

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

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

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

    【讨论】:

    • 你是说如果服务 SSL SHA-2 GoDaddy 证书的服务器安装了这个交叉根证书包,那么 Java 将能够在不修改 java lib/security/cacert 链的情况下连接到它?
    • 假设您不必修改 java 证书即可使交叉证书正常工作。但是,我发现 SHA2 G2 证书现在包含在默认的 Java 安全存储中。我安装了 Java 8u31。
    【解决方案7】:

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

    【讨论】:

      【解决方案8】:

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

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

      【讨论】:

        【解决方案9】:

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

        降级到 SHA1 并不是一个理想的选择,因为它已被弃用,并且会导致您在未来进行更多工作。幸运的是,GoDaddy 提供了一个交叉证书来解决这个问题。他们发布了韦恩复制的说明,他们被埋葬了in the comments here

        我已经使用 SHA2 证书亲自测试过这个解决方案,它运行良好。与重新键入和降级到 SHA1 相比,这是一个更优越的解决方案。当需要 SHA2 时,此选项无论如何都不可用,并且可能仍然存在没有新证书的 Java 工具链。

        根据 GoDaddy 支持,截至 2014 年 7 月,正确的根证书已包含在 Java 8 的最新版本中,并且在 2014 年 9 月,GoDaddy 的 Wayne Thayer also said 认为该证书“计划添加到 Java 中接下来的几个月”。我已经检查了 Java 8 for Mac OS downloaded from here 中的 cacerts 文件,它确实包含 SHA2 根证书。

        所以你的链不是这样的:

        • Go Daddy 根证书颁发机构 – 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 证书

        应该是这样的:

        • Go Daddy 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 根证书颁发机构 – 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.

        【讨论】:

        • “GoDaddy 还表示该证书将包含在未来的 Java 版本中。”你能指出说的地方吗?这是一个在一年多的时间里多次报告的未解决问题(中间有许多 Java 版本),并且在报告之前已经存在很多年了(G2 CA 服务器的证书是在 2009 年签署的,所以它是到目前为止,这个问题已经存在 5 年以上)。此外,当全新和/或无活动帐户发布这些变通办法作为答案时,也是值得怀疑的。
        • 这场战斗我没有狗。我只是想在那里找到正确的解决方法。您可能对 GoDaddy 有合法的问题,但请不要将其归咎于我或来这里寻找可行解决方案的人。降级到 SHA1 的投票最多的解决方案是不安全的,并且与 SHA1 弃用不兼容。我同意根 CA 需要进入 Java,但是服务器端的解决方法是处理已经发布的没有证书的 Java 版本的唯一方法。请停止对发布 GoDaddy 发布的解决方法的人投反对票。
        • 我确实注意到了时间线,并且我认识到这个线程比 GoDaddy 关于如何解决它的博客文章更早。尽管如此,几个月来有人一直在否决唯一可行的解​​决方案。这种行为浪费了我和我团队的大量时间。
        • 我正在尝试在 Windows 2003 上安装交叉证书。我正在按照这些说明进行操作technet.microsoft.com/en-us/library/dd441378(v=office.13).aspx 这是安装交叉证书的正确方法吗?我已经这样做了,但仍然有问题。
        • "在您的证书捆绑文件中安装 GoDaddy G1 到 G2 交叉证书以及中间证书。" -- 我该怎么做?我正在运行 Apache 2.2
        【解决方案10】:

        如果您将 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
        

        【讨论】:

          【解决方案11】:

          您可以尝试以下方法。在运行时将 GoDaddy 根证书和中间证书添加到信任管理器。即如果应用程序启动。

          静态最终字符串 GD_CERT1 = //"-----开始证书-----" “MIIE0DCCA7igAwIBAgIBBzANBgkqhkiG9w0BAQsFADCBgzELMAkGA1UEBhMCVVMx” +“EDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxGjAYBgNVBAoT” +“EUdvRGFkZHkuY29tLCBJbmMuMTEwLwYDVQQDEyhHbyBEYWRkeSBSb290IENlcnRp” +“ZmljYXRlIEF1dGhvcml0eSAtIEcyMB4XDTExMDUwMzA3MDAwMFoXDTMxMDUwMzA3” +"MDAwMFowgbQxCzAJBgNVBAYTAlVTMRAwDgYDVQQIEwdBcml6b25hMRMwEQYDVQQH" +"EwpTY290dHNkYWxlMRowGAYDVQQKExFHb0RhZGR5LmNvbSwgSW5jLjEtMCsGA1UE" +"CxMkaHR0cDovL2NlcnRzLmdvZGFkZHkuY29tL3JlcG9zaXRvcnkvMTMwMQYDVQQD" +"EypHbyBEYWRkeSBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5IC0gRzIwggEi" +"MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC54MsQ1K92vdSTYuswZLiBCGzD" +"BNliF44v/z5lz4/OYuY8UhzaFkVLVat4a2ODYpDOD2lsmcgaFItMzEUz6ojcnqOv" +"K/6AYZ15V8TPLvQ/MDxdR/yaFrzDN5ZBUY4RS1T4KL7QjL7wMDge87Am+GZHY23e" +"cSZHjzhHU9FGHbTj3ADqRay9vHHZqm8A29vNMDp5T19MR/gd71vCxJ1gO7GyQ5HY" +"pDNO6rPWJ0+tJYqlxvTV0KaudAVkV4i1RFXULSo6Pvi4vekyCgKUZMQWOlDxSq7n" +“eTOvDCAHf+jfBDnCaQJsY1L6d8EbyHSHyLmTGFBUNUtpTrw700kuH9zB0lL7AgMB” +"AAGjggEaMIIBFjAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNV" +"HQ4EFgQUQMK9J47MNIMwojPX+2yz8LQsgM4wHwYDVR0jBBgwFoAUOpqFBxBnKLbv" +"9r0FQW4gwZTaD94wNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8v" +"b2NzcC5nb2RhZGR5LmNvbS8wNQYDVR0fBC4wLDAqoCigJoYkaHR0cDovL2NybC5n" +"b2RhZGR5LmNvbS9nZHJvb3QtZzIuY3JsMEYGA1UdIAQ/MD0wOwYEVR0gADAzMDEG" +“CCsGAQUFBwIBFiVodHRwczovL2NlcnRzLmdvZGFkZHkuY29tL3JlcG9zaXRvcnkv” +“MA0GCSqGSIb3DQEBCwUAA4IBAQAIfmyTEMg4uJapkEv/oV9PBO9sPpyIBslQj6Zz” +"91cxG7685C/b+LrTW+C05+Z5Yg4MotdqY3MxtfWoSKQ7CC2iXZDXtHwlTxFWMMS2" +"RJ17LJ3lXubvDGGqv+QqG+6EnriDfcFDzkSnE3ANkR/0yBOtg2DZ2HKocyQetawi" +"DsoXiWJYRBuriSUBAA/NxBti21G00w9RKpv0vHP8ds42pM3Z2Czqrpv1KrKQ0U11" +"GIo/ikGQI31bS/6kA1ibRrLDYGCD+H1QQc7CoZDDu+8CL9IVVO5EFdkKrqeKM+2x" +"LXY2JtwE65/3YR8V3Idv7kaWKK2hJn0KCacuBKONvPi8BDAB"; //+"-----结束证书-----";

          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());
          }
          

          我从我的工作版本中复制了代码。所以可能会出现并发症错误。你只需要解决这些问题。

          【讨论】:

            猜你喜欢
            • 1970-01-01
            • 1970-01-01
            • 2017-03-11
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            • 2012-11-21
            • 1970-01-01
            • 2017-08-20
            相关资源
            最近更新 更多