SSL 握手失败 - 一个威瑞信链证书 - 包含两个 CA 签名证书和一个自签名证书答案

【问题标题】：SSL handshake fails with - a verisign chain certificate - that contains two CA signed certificates and one self-signed certificateSSL 握手失败 - 一个威瑞信链证书 - 包含两个 CA 签名证书和一个自签名证书
【发布时间】：2011-05-05 10:41:55
【问题描述】：

我遇到了一个问题并试图调试它。我们购买了威瑞信证书。当我们使用：

openssl> s_client -connect myweb.com:443 -showcerts

SSL 握手从未完成，最后我们看到错误：

Verify return code: 19 (self signed certificate in certificate chain)

它显示了 3 个---BEGIN/END CERTIFICATE--- 标签。链中的两个证书是 Verisign 签名的，但一个是自签名的。

如果有人能解释一下这个自签名证书是如何出现在 CA 签名证书中的？
这个错误19 (self signed certificate in certificate chain) 是良性的吗？如果不是，可能是什么原因造成的？
客户端在受信任的存储中拥有 CA 证书，但自签名证书没有任何内容。你认为这会导致问题吗？如果是，我该怎么做：
1. 如何从链证书中删除自签名证书，只留下链中的 2 个 CA 签名证书？
2. 将此自签名证书添加到客户端可信存储？

【问题讨论】：

谢谢布雷茨基。我将检查中间证书。我想添加更多信息：当客户端发送上述 openssl 命令时，“client hello”到达服务器，但我们从未在客户端收到“server hello”。如果缺少中间证书，您是否期望这种行为？设备是windows mobile设备，服务器是apache web server。
证书加载在什么类型的服务器/设备上？
您可以通过 OpenSSL 从其他设备/计算机进行连接吗？哪个版本的 Windows Mobile，我对 Windows mobile 和安全证书有过噩梦般的体验。
尝试向服务器发送一个空行作为输入：echo "" | openssl ....

标签： ssl openssl handshake

【解决方案1】：

关于服务器是否可以向客户端提供根证书，从 RFC-5246 'The Transport Layer Security (TLS) Protocol Version 1.2' 文档中提取：

证书列表
这是证书的序列（链）。发件人的证书必须排在列表的首位。以下每一个证书必须直接证明它之前的证书。因为证书验证要求分发根密钥独立地，指定根的自签名证书证书颁发机构可以从链中省略，
假设远端必须已经拥有它才能无论如何都要验证它。

关于“MAY”一词，摘自 RFC-2119“最佳当前实践”：

5.5 月
这个词，或形容词“可选”，意味着一个项目是真正可选的。一位供应商可能会选择包含该项目，因为
特定市场需要它，或者因为供应商认为
它增强了产品，而其他供应商可能会省略相同的项目。
不包含特定选项的实现必须是
准备与另一个实现互操作
包括该选项，尽管功能可能有所减少。在里面同样包含特定选项的实现
必须准备好与另一个实现互操作
不包括该选项（当然，对于该功能
选项提供。）

总之，根可能在握手中服务器传递的证书路径上。

实际用途。
考虑一下，不要用导航器用户的术语，而是用互联网访问受限的军事区服务器上的传输工具来考虑。
服务器在传输时扮演客户端角色，从服务器接收所有证书路径。
应检查链中的所有证书是否受信任，包括根。
检查这一点的唯一方法是在传输时将根包含在证书路径中，与之前声明为“受信任”的本地副本进行匹配。

【讨论】：

【解决方案2】：

当您看到“Verify return code: 19 (self signed certificate in certificate chain)”时，要么服务器真的在尝试使用自签名证书（客户端永远无法验证），要么 OpenSSL 无法访问必要的根，但服务器试图自己提供它（它不应该这样做，因为它没有意义——客户端永远不能信任服务器提供与服务器自己的证书相对应的根）。

同样，添加 -showcerts 将帮助您诊断哪个。

【讨论】：

【解决方案3】：

这里是 VeriSign 的 SSL 证书安装检查器的链接：https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=AR1130

输入您的 URL，点击“测试此 Web 服务器”，它会告诉您您的中间证书颁发机构是否存在问题。

【讨论】：

在 Mac：safari、firefox 和 chrome 以及 Win：IE 和 Firefox 上尝试过该工具。它在所有情况下都失败了。 POS

【解决方案4】：

由 CA 颁发的根证书只是自签名证书（可反过来用于颁发中间 CA 证书）。它们并没有什么特别之处，只是它们已在许多浏览器或操作系统信任锚中默认导入。

虽然浏览器和某些工具默认配置为在位置查找受信任的 CA 证书（其中一些可能是自签名的），但据我所知 openssl 命令不是。

因此，任何提供完整证书链的服务器，从其最终实体证书（服务器的证书）到根 CA 证书（可能带有中间 CA 证书）都将在链中拥有一个自签名证书：根 CA。

openssl s_client -connect myweb.com:443 -showcerts 没有任何特别的理由信任 Verisign 的根 CA 证书，因为它是自签名的，您将获得“证书链中的自签名证书”。

如果您的系统有一个位置包含默认信任的证书包（我认为 RedHat/Fedora 上的 /etc/pki/tls/certs 和 Ubuntu/Debian 上的 /etc/ssl/certs），您可以配置 OpenSSL 以将它们用作信任锚，例如像这样：

openssl s_client -connect myweb.com:443 -showcerts -CApath /etc/ssl/certs

【讨论】：

OS X 的 -CApath 是什么？
我不认为 OSX 默认有一个，因为它依赖于钥匙串。您可以进入钥匙串访问，选择“系统根目录”中的所有证书（除了那些被划掉的证书，如果有的话），右键单击并将所有项目导出到 PEM 文件中，然后使用-CAfile（而不是-CApath）指向该文件。
@Bruno 我如何在 Windows 中获得 tursted 认证？他们在注册表中。我无法获得 -CAfile 和 -CApath
@Jonathan ：尝试使用certifi.io/en/latest - “在验证 TLS 主机身份的同时验证 SSL 证书的可信度的精心策划的根证书集合”。它提供可下载的 CA 包或 Python/Ruby/Node/Go/Erlang 包。
我仍然收到verify error:num=19:self signed certificate in certificate chain

【解决方案5】：

听起来好像缺少中间证书。 自 2006 年 4 月起，VeriSign 颁发的所有 SSL 证书都需要安装中间 CA 证书。

可能是您的服务器上没有加载整个证书链。一些企业不允许他们的计算机下载额外的证书，导致无法完成 SSL 握手。

这里有一些关于中间链的信息：
https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=AR657
https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=AD146

Intermediate CA Certificates

【讨论】：