通过 Curl 访问时在有效证书上获取 SSL 证书错误

Question

我有一个通配符 SSL 证书，它为*.mysite.com. 该网站可以从所有浏览器访问，没有任何问题。还有一个服务（在不同的服务器上）的 URL: service.mysite.com。奇怪的是，当我service.mysite.com使用 curl访问时，我得到了这个：

curl: (60) SSL certificate problem: certificate has expired

在进一步挖掘时，我发现我确实可以service.mysite.com从 Ubuntu 18.04 服务器访问，但不能从 Ubuntu 14.04 访问。这告诉我，也许我的 CA 包不正常。

所以我这样做了：

curl -vv --cacert mysite.ca-bundle.crt https://service.mysite.com

mysite.ca-bundle.crt是我从 SSL 提供商那里收到的。但我仍然得到完全相同的错误。我错过了什么？

Answer 1

您没有提供网站的实际地址，也没有提供 SSL 提供商的名称，也没有提供有关证书的任何其他信息，基本上是希望我们猜测各种可能的原因。

我的猜测是您的证书链以“AddTrust External Root”作为最顶层的 CA 结束，而该根证书在几个小时前刚刚过期。

证书的所有者 Sectigo有一张链图——由于旧 CA 证书交叉签署新证书，“AddTrust External Root”基本上比通常是公司实际根 CA 的级别更高。新操作系统会将 Sectigo/Comodo 的证书视为自签名根 CA，而旧操作系统会将它们视为 AddTrust Root 下的中间 CA。

所以在旧的操作系统上，只能通过 AddTrust Root CA 证书的交叉签名来识别 Sectigo，一旦后者过期，整个链就无效了。要解决此问题，您必须切换到这些系统识别为根的另一个 CA（检查/etc/ssl/certs）。

可能这些系统确实将 Sectigo 识别为根 CA。从理论上讲，是用于通过多个链的证书来验证，例如CA可以同时是一个根完全合法的和由另一个CA被交叉签署

但在实践中，许多 TLS 客户端库在构建备用链方面非常糟糕，并假设总是只有一种方法来验证证书。（Windows 好一点，大型 Web 浏览器还包含代码来处理这种额外的复杂性，而不是 TLS 库将要探测的内容。）

例如，旧版本的 OpenSSL对哪些证书可以充当信任根非常严格。如果服务器发送一个链“OldCA–NewCA–Intermediate–MyServer”，OpenSSL 1.0只会接受如果你有“OldCA”作为受信任的证书——但如果你有“NewCA”，它就不够聪明接受它.

因此，如果 Ubuntu 14.04 已经将 Sectigo 识别为证书颁发机构，那么您需要修复由您的网络服务器发送的证书链 - 我怀疑删除显示“Issuer: AddTrust”的证书就足够了。

假设旧证书链如下所示：

[AddTrust External Root]                               [included in OS]
+-- USERTrust RSA Certification Authority (Sectigo)    sent by your server
    +-- Gandi Standard SSL CA 2                        sent by your server
        +-- git.kernel.org                             sent by your server

您需要对其进行编辑，以便您的服务器停止发送交叉签名的 USERTrust 证书：

[USERTrust RSA Certification Authority (Sectigo)]      [included in OS]
+-- Gandi Standard SSL CA 2                            sent by your server
    +-- git.kernel.org                                 sent by your server

您还可以通过删除 AddTrust 根 CA在客户端修复此问题。