我希望有人能幫助我，因為我很茫然。我的團隊一直面臨服務中缺少中間證書的問題。我的任務是編寫一個腳本，不斷地一一測試我們所有的高流量服務 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 次測試，並全部通過了 12 次。可能這兩個腳本只是訪問了不同的伺服器，但對我來說這似乎很可疑。
正如我所說，我們不知道為什麼會發生這種情況。我讓我們的服務工程師檢查了負載平衡器，他們說它工作正常。我們還沒有找到任何導致測試開始失敗的模式。你們有人知道為什麼會發生這種情況嗎？或者，當我們使用 :443 進行測試時，有沒有辦法知道哪個實例連接埠被命中？我們可能需要更改為在實例連接埠而不是 :443 上進行測試，但我們的實例計數會定期更改，而且數量很多。
預先感謝您提供的任何幫助！
太長了；博士：我們的 URL 上的 443 連接埠不會傳回中間證書，但是當我們檢查該 URL 的各個伺服器時，總是會找到中間證書。