嗨,

所以我有多个域运行，让加密证书没有任何问题。但现在我们有了一个新的域名，在那里我们看到了一些奇怪的行为。我们有一个跨计算机部署的代理，用于将数据报告给使用HTTPS路由的服务器。在一个组织内，一些计算机成功地验证了证书，一些计算机失败了。

如果我检查fullchain.pem/chain.pem，它们只包含DST Root CA X3中间体，我猜这就是它失败的原因？

我们的证书是通过运行certbot和手动配置的Apache来生成的，它提供了每个证书，包括Chain/cert/key，并在Ubuntu 14.04上运行。

所以我在这里试着理解几件事：

为什么有些计算机试图根据X1而不是X3进行验证，这是我们可以从服务器控制的吗？

我可以/应该将这两个中间体都添加到链文件中吗？如果是这样的话，我如何使用certbot来做到这一点？

如果1或2都不能解决问题，我该怎么办？

我在互联网和你的论坛上努力搜索了一下，没有发现任何类似的案例。

谢谢！，Hi@GSU

GSU：

但现在我们有了一个新的域名，在那里我们看到了一些奇怪的行为。

域名是什么？

GSU：

如果我检查fullchain.pem/chain.pem，它们只包含DST Root CA X3中间体，我猜这就是它失败的原因？

DST根CA X3是根证书，而不是中间证书。所以它应该是预装的。

但是您的服务器应该发送中间证书。

或许可以使用SSL服务器测试(由Qualys SSL Labs提供支持)检查您的服务器

在那里，您应该会看到一条路径，如：

由服务器发送

由服务器发送

在信任商店中

不好的是2.额外下载，Hi@JuergenAuer，

感谢您的回复！

我已经检查了sslLab，它报告一切正常。

尤尔根·奥尔：

DST根CA X3是根证书，而不是中间证书。所以它应该是预装的。

是的，但据我所知，每个根证书都与一个中间证书相连。因此，如果我要启用2个根证书来验证我的证书，那么我将需要这两个中间证书。但也许我误解了它的工作原理？

我们的服务器确实发送了1个中间证书，但我想知道它是否需要为每个根证书发送一个中间证书，即发送2个不同的中间证书，而不是1个。因为如果我查看ssllab，我只看到Windows修补程序中的X3作为根证书：

我看到了他们两个：

Image.png786×707 37.2 KB

因此，总结一下：

为什么计算机选择的根证书不在我的路径中？

我如何解决这个问题，让他们总是选择X3，或者我们的服务器也会批准X1验证？

谢谢你的帮忙!真的很感谢！嗨，

首先，现在Microsoft Windows不信任ISRG Root X1。

如果服务器发送由ISRG根X1签名LE中间件，

Windows上的浏览器下载终端实体证书中显示的由DST Root CA X3签名的LE中间件。

但我认为这种方法只在Microsoft Windows上可用。

这样，如果服务器实际发送的中间证书(在本例中由ISRG Root X1签署)不能在可信路径中解析，客户端可以尝试获取最终证书中报告的另一个中间证书，如上所述。

如果我们的加密真的想让客户端测试ISRG Root X1证书，它应该已经删除或修复了对DST Root X1签名中间体的引用。谢谢你们的回复！我真的很感激！

归根结底，它仍然是：

为什么当我发送X3的中间件时，计算机会尝试X1？

最重要的问题是：我如何修复它，以及它能在服务器端得到修复吗？

谢谢！，GSU：

最重要的问题是：我如何修复它，以及它能在服务器端得到修复吗？

我在线程中没有发现工作客户和非工作客户之间的实际区别。它们是不同的操作系统吗？或者可能是同一操作系统的不同版本？

也许不工作的客户端与DST Root X3有问题，但如果没有更多关于客户端的信息，我们就不能确定是否知道，因为我不控制机器，所以我不知道。但我们有数千台计算机通过不同的域进行报告，所有计算机都使用相同的certbot配置来生成SSL，我从未听说过这个问题，直到这个特定的客户。这并不意味着它不存在于其他客户身上，但我有一种感觉，如果它至少是常见的，我应该遇到它。因此，我最初的感觉是，在客户端有一些东西使得它更倾向于X1证书而不是X3证书。我正在与他们的技术人员合作，试图找到原因，但我只能从我这边进行调查，也就是服务器及其证书。它们都是同一个AD中的Windows机器，但它们确实有一堆安全套装。例如，Barracuda Web Security，它似乎具有一些验证SSL的功能，所以我们正在调查这是否也会扰乱这一点。他们还有BitDefender和McAfee，以及标准的Windwos Defender，我猜这也可能会导致在混合这么多安全套件时出现一些意想不到的行为。

他们已经试图将X1和X3添加到他们信任的根存储中，但没有起到任何作用。

来自cpprestsdk的错误是：WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED to check Revocation Status。

有没有什么我可以传递给certbot的东西，使它包括两个中间人来在发球时解决这个问题？如果有可能同时支持这两种方法，那当然是最好的方法，而且我想这也是未来的证据。但这可能会带来不同的问题？，我认为证书验证路径取决于客户端。

例如,

我认为验证Mozilla Firefox使用的路径取决于浏览器的用户活动。

但我对此知之甚少。

我正在使用ISRG Root X1链来验证由Firefox稳定和夜间的DST Root CA X3签名的中间证书。

我正在使用DST Root CA X3链来验证由Firefox Developer Edition中的DST Root CA X3签署的带有中间签名的证书。

有没有什么我可以传递给certbot的东西，使它包括两个中间人来在发球时解决这个问题？如果有可能同时支持这两种方法，那当然是最好的方法，而且我想这也是未来的证据。但这可能会带来不同类型的问题？

不，那行不通的。链中的每个证书都必须在其前面的证书上签名。中间商的抢劫袋是无效的。有些客户会忽略该错误，有些客户将无法验证它。谢谢所有回复！

根据这张图，他们是交叉签名的，而不是我所理解的直链。这不是意味着它们应该能够用X1或X3进行验证吗？我想如果其中一个失败了，它应该尝试另一个，并且任何一个都应该能够验证证书。还是我误解了它？

Image.png1425×900 22.8 KB

如果是这样的话，如果X1同时受到服务器(不是中间人)和客户端的信任(如在前面的示例中转到验证站点时所看到的)，那么它为什么不能针对X1进行验证。

根据这张图，他们是交叉签名的，而不是我所理解的直链

该图像具有误导性：有两个不同“让我们加密授权机构X1”，一个由“ISRG根1”信任，另一个由“DST根CA X3”信任

(但是，因为它们共享相同的密钥和名称，所以两者都被识别为对叶证书有效)

GSU：

这不是意味着它们应该能够用X1或X3进行验证吗？

不能，中间项只能针对一个根进行验证。这就是为什么有一个X1中间对X1根有效，另一个X1中间对X3有效。

您的服务器应该将它认为会被客户端识别为可信的邮件发送到服务器。

客户端可以决定使用另一条路径。例如，如果您的服务器发送了“让我们加密由ISRG根1签署的授权X1”，但客户端仍在缓存中(因为另一个网站之前发送了它)“让我们加密由DST根CA X3信任的授权X1”，则客户端可能会使用该选项。

GSU：

如果是这样，那么如果X1同时受到服务器(而不是中间人)和客户端的信任(正如在前面的示例中转到验证站点时所看到的)，那么它为什么不能针对X1进行验证呢？

服务器信任的根目录并不重要。

如果您的客户端信任X1根目录，但没有收到链接到它的中间目录，那么它可能会失败。

您的客户端也可以使用证书的caIssuers字段(1.3.6.1.5.5.7.48.2)获取中间件。

来自cpprestsdk的错误是：WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED to check Revocation Status。

你对那个错误进行了更多的调查吗？这意味着客户端无法检查证书是否已被吊销。要检查它以获取我们要加密的证书，客户端需要能够获取OCSP。如果您的客户端无法获取它，它可能会认为这是一个致命的错误。您可以强制您的服务器发送OCSP信息，以避免使用OCSP装订。非常感谢您的详细回答！

我将更深入地研究吊销错误，但我认为这只是尝试针对错误的根证书进行验证的副作用。

有没有办法同时支持两个根证书，或者强制客户端跳过缓存并选择X3根证书进行验证？我猜解决方案可能是从AD中该客户的受信任根存储中删除ISRG，对吗？，GSU：

我猜解决方案可能是从AD中该客户的受信任根存储中删除ISRG，对吗？

是的，应该能行得通。但我不会推荐它：

您不能强制客户端选择验证路径。但是，只要您为他提供一条有效的路径，它就不会影响证书验证的其他部分(吊销，...)

事实上，证书的吊销是使用证书提供的信息来完成的，而不是使用路径中使用的中间件。

如果您使用一种方法来固定根目录或中间目录(在这种情况下，您可以固定多个根目录/中间目录)，那么唯一一件事(如果我没有弄错的话)是经过验证的路径影响是证书固定。因此，经过更多的研究后，我发现：

Letsencrypt.org

让我们加密所有主要Root程序信任的Root-让我们加密-免费...

截至2018年7月底，我们的加密根--ISRG Root X1受到微软产品的直接信任。我们的根现在得到了所有主要根程序的信任，包括微软、谷歌、苹果、Mozilla、甲骨文和黑莓。

今天的公告……

似乎当他们将ISRG根证书放入Windows可信存储时，事情开始崩溃，因为计算机现在将开始尝试并根据ISRG根证书进行验证，而ISRG根证书不是默认链的一部分，而默认链似乎会破坏它。不确定这是否是cpprestsdk中的问题，让我们在某个地方加密证书或配置。但我的猜测是，在未来几天里，我不会是唯一一个遇到这些问题的人。我会进一步调查这一点，但我真的很感谢大家可能提供的任何意见。

是否可以切换并使用ISRG证书路径而不是DST？如果是这样的话，是如何做到的？GSU：

似乎是在他们将ISRG根证书放入Windows受信任的存储区时

微软必须在下一个补丁日部署它。我的Windows 10没有这个功能。

GSU：

因为计算机现在将开始尝试并根据ISRG根证书进行验证，该证书不是默认链的一部分，这似乎会破坏它。

这是具有两个不同根的相同中间证书。JuergenAuer：

微软必须在下一个补丁日部署它。我的Windows 10没有这个功能。

我再次看到(边缘)DTS根CA X3作为根证书(浏览器视图)。

证书存储没有证书(不是用户，也不是计算机)。