伺服器查詢ssl證書有效期（SSL如何防止被黑客破壞）

2023-10-24 00:06:00 2

在早年，Apache官方伺服器網站曾被國內知名網絡黑客安全專家郭盛華發現嚴重漏洞。Apache的錯誤證書，對於眾多技術人員來說，這些複雜性的最新來源是公鑰基礎結構（PKI），它是用於維護網絡上安全連接的安全性基礎結構，如果其他任何人在Windows中遇到相同的看似莫名其妙的行為，我也想在這裡重述一下我的經驗。他們的PKI配置。這些天來與運行您自己的Web伺服器相關的複雜性給我留下了深刻的印象。

對我而言，所有這一切都始於以下想法：在嘗試了數年的嘗試後，現在是時候升級我的Web伺服器系統，使其包含重寫規則以推動所有HTTP（未加密）請求使用傳輸層安全性來使用安全會話了（TLS）。這不僅僅是時間，這遠遠超出了時間！

同時，我認為最好升級基礎Web伺服器硬體以更新Web平臺以滿足當前的流量需求。

因此，我開始了將整個Web服務環境遷移到運行最新版本軟體集的不同硬體平臺的路徑。所有值得稱讚的目標，所以我想！

該決定意味著必須改變服務的許多方面。以前平臺上的作業系統停留在FreeBSD 11.2上，當前發行版本是12.1。我的託管框架在Apache 2.4配置上使用虛擬託管。舊主機使用Apache版本2.4.35，而新系統使用Apache版本2.4.41。在舊主機上，所有虛擬主機都被加載到一個監聽所有接口的Apache實例中。這次圍繞虛擬主機分配了兩個Apache實例，每個實例偵聽不同的IP位址，以便在平臺中執行某種級別的負載隔離。

在此過渡過程中，有許多活動的部分，在執行遷移的每個步驟時，我們都會仔細檢查新服務的完整性。

讓我們加密證書

這裡的問題之一是確保未破壞SSL配置。除了拆分虛擬主機定義外，此步驟還更改了Apache中的證書聲明。舊系統使用了以下配置：

SSLCertificateFile「 /dir/cert.pem」 SSLCertificateChainFile「 /dir/fullchain.pem」

看來這些天我們應該使用稍微不同的模板：

SSLCertificateFile「 /dir/cert.pem」 SSLCertificateChainFile「 /dir/chain.pem」

區別在於，Let's Encrypt的「全鏈」證書同時具有由Digital Signature Trust Co.頒發的對Let's Encrypt進行認證的證書和由Let's的Encrypt進行我的域認證的證書，而「 chain」的證書僅具有父證書由Digital Signature Trust發布。

從理論上講這並不重要，但是我們還是決定使用更新後的模板。我們安裝了軟體，運行了測試（curl中的-resolve選項在實際切換整個環境之前，對測試設置非常有用），然後更改了DNS，並在新的Web平臺上開始了進一步的測試。

使用各種瀏覽器訪問重定位的服務在更改後的配置文件中存在一些打字錯誤的問題。但是，一旦解決了這些問題，一切看起來都很好。

除了一項測試。

OpenSSL

我們使用的測試是使用OpenSSL的客戶端連接。命令是：

$ openssl s_client -connect x.labs.apnic.net:443

輸出量很大，但是這裡值得關注的部分是證書鏈

$ openssl s_client -connect x.labs.apnic.net:443CONNECTED(00000003)depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3verify return:1depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 verify return:1depth=0 CN = y.labs.apnic.netverify return:1---Certificate chain 0 s:/CN=y.labs.apnic.net i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 1 s:/CN=y.labs.apnic.net i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 2 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 i:/O=Digital Signature Trust Co./CN=DST Root CA X3---

這裡有些奇怪。我們正在嘗試通過埠443 通過x.labs.apnic.net連接到虛擬主機，但是提供用於建立連接的證書卻完全不同。這是主機名y.labs.apnic.net的證書。這不是一個完全隨機的選擇，因為在Apache Virtual Host配置中還定義了一個虛擬主機y.labs.apnic.net。

為什麼當我們要求OpenSSL客戶端連接到x.labs.apnic.net時，我們看到Apache伺服器為y.labs.apnic.net提供證書？

試圖了解這種情況的第一步是在不同的主機上嘗試相同的openssl s_client命令，而其他一些主機複製了上面顯示的相同的異常響應，而其他主機的行為與我們預期的一樣：

$ openssl s_client -connect x.labs.apnic.net:443CONNECTED(00000003)depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3verify return:1depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 verify return:1depth=0 CN = x.labs.apnic.net verify return:1---Certificate chain 0 s:CN = x.labs.apnic.net i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 1 s:CN = x.labs.apnic.net i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 2 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 i:O = Digital Signature Trust Co., CN = DST Root CA X3---

我們期望的是cert鏈中的證書0和1：x.labs.apnic.net中的主題名稱。顯然，這是一致的行為。我們使用的每個主機都顯示了其中一種其他行為，但每個測試主機都沒有在這些行為之間切換。它要麼使用了預期的證書，要麼使用了不同的證書來建立SSL會話，並且反覆進行。

此時有兩個問題：

為什麼要提交y.labs.apnic.net證書？

可以通過仔細閱讀Apache文檔來回答第一個問題。可以在基於名稱的虛擬主機的Apache Wiki上找到最佳解釋。

在初始HTTP請求中使用HTTP Host：參數支持HTTP中的虛擬主機。這是此類連接的轉儲：

* Connected to x.labs.apnic.net (2401:2000:6660::109) port 80 (#0)> GET / HTTP/1.1> Host: x.labs.apnic.net> User-Agent: curl/7.64.1> Accept: */*> GET / HTTP/1.1> Host: x.labs.apnic.net> User-Agent: curl/7.52.1> Accept: */*> GET / HTTP/1.1> Host: x.labs.apnic.net> User-Agent: curl/7.64.0> Accept: */*>* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):* old SSL session ID is stale, removing< HTTP/1.1 200 OK

幾乎相同，但是現在會話使用的是TLS版本1.3。這些主機上的OpenSSL庫版本似乎有問題。

Failing hosts: $ openssl version OpenSSL 1.1.0l 10 Sep 2019 Working hosts: $ openssl version OpenSSL 1.1.1d 10 Sep 2019

似乎OpenSSL在1.1.0和1.1.1之間有所更改。

讓我們看一下OpenSSL 1.1.1的文檔 -以及s_client文檔，因為OpenSSL是加密功能的「德克薩斯電鋸殺人狂」，並且該庫具有大量命令和選項！

-servername名稱

將ClientHello消息中的TLS SNI（伺服器名稱指示）擴展名設置為給定值。如果未提供-servername，則TLS SNI擴展名將遵循DNS名稱格式填充給-connect的名稱。如果也未提供-connect，則SNI設置為「 localhost」。這是自OpenSSL 1.1.1以來的默認設置。

即使SNI通常應該是DNS名稱而不是IP位址，但如果提供了-servername，則無論該名稱是否是DNS名稱，都將發送該名稱。

嗯 如果這是自OpenSSL 1.1.1起的默認設置，那麼該版本之前的默認設置是什麼？這是與OpenSSL s_client版本1.1.0相同的手冊條目。

-servername名稱

在ClientHello消息中設置TLS SNI（伺服器名稱指示）擴展名。

現在的含義很明顯：如果未使用此偽指令設置TLS SNI，則ClientHello消息中沒有SNI擴展名。

看來我們已經找到了問題。讓我們檢查一個OpenSSL 1.1.0客戶端，為servername參數添加一個值：

$ openssl s_client -connect x.labs.apnic.net:443 -servername x.labs.apnic.net CONNECTED(00000003)depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3verify return:1depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 verify return:1depth=0 CN = x.labs.apnic.net verify return:1---Certificate chain 0 s:/CN=x.labs.apnic.net i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 1 s:/CN=x.labs.apnic.net i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 2 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 i:/O=Digital Signature Trust Co./CN=DST Root CA X3------

讓我們通過提供與連接名稱參數不同的servername參數值來確認：

$ openssl s_client -connect x.labs.apnic.net:443 -servername dmm.labs.apnic.net CONNECTED(00000003)depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3verify return:1depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 verify return:1depth=0 CN = dmm.labs.apnic.net verify return:1---Certificate chain 0 s:/CN=dmm.labs.apnic.net i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 i:/O=Digital Signature Trust Co./CN=DST Root CA X3---

現在，我們對第二個問題有了答案。這就是我們在具有OpenSSL版本1.1.0的主機上使用openssl -s_client的方式。通過省略-servername參數，我們觸發了此行為。

正確的證書

因此，我們已經找到了問題。Apache沒有錯，Let's Encrypt證書沒有錯，瀏覽器沒有錯。OpenSSL中甚至沒有任何「錯誤」。

但是，跨版本的OpenSSL庫中的診斷工具之一的默認行為存在細微的不一致。

安全旨在幫助我們構建更強大的系統。但是使用PKI，我們擁有數量驚人的活動部件，現在即使在每個組件中，不同版本的診斷工具也可能具有不同的默認行為。

我們經常聽到「安全很難」。但是，從推動和推動Web伺服器配置以及瀏覽搜索結果這一天開始，我的收穫與眾不同。如今，「安全性已變得晦澀難懂」，這是不應該發生的事情！（歡迎轉載分享）