我希望有人能帮助我，因为我很迷茫。我的团队一直受到服务中缺少中间证书的问题的困扰。我的任务是编写一个脚本，该脚本将不断逐一测试我们所有高流量服务 URL，以验证证书链是否完整。我编写了一个运行 OpenSSL 并解析输出的 C# 程序。这是我在每个 URL 上运行的 OpenSSL 命令：
"openssl.exe s_client -showcerts -servername " + uri + " -verify_hostname " + uri + " -connect " + uri +":" + port
或者
openssl.exe s_client -showcerts -servername www.euro-example-01.com -verify_hostname www.euro-example-01.com -connect www.euro-example-01.com:443
端口默认为 443，99% 的时间都在使用。如果 OpenSSL 返回“Verify return code: 21 (unable to verify the first certificate)”，我就会知道缺少中间证书，并会发出警报。此外，OpenSSL 会输出链以供我验证。这在针对 incomplete-chain.badssl.com 等网站进行测试时很有效。
它现在在云中持续运行，偶尔会发出警报。但是，很多时候我们的服务工程师会使用实例端口检查故障 URL 的每个服务器，我们会发现0 例失败。我们使用循环负载平衡，因此我们难道不应该预计这些单个服务器中至少有一个是导致 443 失败的原因吗？:443 失败案例的 OpenSSL 日志显示链中只有一个证书，SSLLabs 等网站也确认缺少中间证书。
如果我们的工程师重新启动了有问题的端点，那么就会找到完整的链，并且缺少中间体的警报就会消失。
也许最奇怪的是，我设置了一个单独的脚本来测试 4 个 URL，而不是所有约 160 个不同的 URL。昨天在 30 分钟的时间范围内，euro-example-01.com:443对原始脚本进行了 12 次测试，其中 6 次失败。在新的、较小的测试大小脚本上，同样的 30 分钟内euro-example-01.com:443进行了 12 次测试，并且全部通过。可能是这两个脚本只是访问了不同的服务器，但在我看来这很可疑。
正如我所说，我们不知道为什么会发生这种情况。我让服务工程师检查了负载平衡器，他们说它工作正常。我们还没有找到导致测试开始失败的任何模式。你们有人知道为什么会发生这种情况吗？或者，有没有办法知道当我们使用 :443 进行测试时哪个实例端口被命中？我们可能需要改为在实例端口上进行测试，而不是 :443，但我们的实例数量经常变化，而且数量很多。
提前感谢您提供的任何帮助！
总结：我们的 URL 上的 443 端口不会返回中间证书，但是当我们检查该 URL 的各个服务器时，总会找到中间证书。