自簽名證書的情況下，瀏覽器是否不驗證數字簽名

Question

在以下用例中，我對SSL證書流程的理解是否正確（CA /自簽名）。 通常，當我們生成SSL證書時，它具有以下內容：

• 諸如所有者，域，有效性等詳細信息。
• Web服務器的公鑰（用於非對稱密鑰對SSL握手）
• 由CA私鑰或“自簽名”簽名的數字簽名將是Web服務器自己的私鑰（希望這種理解正確嗎？（Q1））

第一個Web瀏覽器使用自己的公鑰獲取SSL證書。 CA提供者證書存在時的證書驗證：

1. 瀏覽器將擁有CA的所有公鑰，因此可以驗證數字簽名。
2. 以后，Web服務器提供的公共密鑰用於啟動對稱秘密密鑰加密。

但是博客還談到瀏覽器已經具有受信任的根證書，並且可以進行驗證。 這是否意味着瀏覽器多次僅檢查證書內容而不進行數字簽名驗證（Q2）？

現在，在使用自簽名的情況下，Web服務器將使用其自己的私鑰來登錄證書（而不是CA私鑰）。 在第一次瀏覽器交互期間，它將與網絡服務器公共密鑰一起發送其證書。 因此，在這種情況下，我們在證書簽名期間使用了相同的公鑰/私鑰對，並共享了用於數據加密的對稱密鑰（Q3）？

現在，博客說我們可以在瀏覽器上手動導入證書。 證書導入是否也會導入公鑰以驗證簽名正確（Q4）？ 博客說，如果“受信任的根”證書中存在證書，則認為該證書有效。 這是否意味着瀏覽器不執行簽名驗證（Q5）？

有誰幫助我理解第一季度到第五季度。 我有什么想念的嗎？

Answer 1

您的帖子很難追蹤，但我會盡力的。

如果在瀏覽器中安裝了證書頒發機構（CA）的根證書，則證書將根據頒發的證書頒發機構（CA）進行驗證。

對於自簽名證書， 您是CA。

如果創建證書並為CA導入證書，則使用它創建的證書將受到信任。 如果您不導入CA的證書，那么您的證書將不會被信任。

但是博客還談到瀏覽器已經具有受信任的根證書，並且可以進行驗證。

您的瀏覽器信任的CA的初始根證書集由瀏覽器的發布者安裝。 這意味着，例如，全新安裝的Chrome將信任您的銀行的Verisign頒發的SSL證書，而不是您的自簽名證書。

從您自己的CA安裝根證書后，瀏覽器將像信任Verisign一樣信任您的證書。

至於標題中的問題，瀏覽器必須驗證簽名。 如果沒有，它就壞了，這將是一個巨大的安全漏洞。

Answer 2

由CA私鑰或“自簽名”簽名的數字簽名將是Web服務器自己的私鑰（希望這種理解正確嗎？（Q1））

正確。 服務器的證書將由CA證書（根CA或更常見的是中間CA）簽名。 如果是自簽名證書，則服務器的證書和CA是相同的證書。

2. 稍后，Web服務器提供的公共密鑰用於啟動對稱秘密密鑰加密。

這僅適用於RSA密鑰交換。 使用RSA Kx，可以由客戶端創建主密碼，並使用服務器的公鑰進行加密並將其發送到服務器。 然后，客戶端和服務器都從該主密碼之前的秘密中獲取所有對稱密鑰。

RSA密鑰交換已被棄用，並隨TLS 1.3一起刪除。 相反，應使用Diffie Hellman密鑰交換。 使用DH Kx，服務器證書和內部的公鑰僅用於認證服務器，以防止中間人攻擊，但不參與密鑰交換。

但是博客還談到瀏覽器已經具有受信任的根證書，並且可以進行驗證。 這是否意味着瀏覽器多次僅檢查證書內容而不進行數字簽名驗證（Q2）？

服務器發送服務器（葉）證書和可能的中間證書，然后瀏覽器從葉證書創建到本地根證書（信任錨）的信任鏈。 如果無法創建此類信任鏈，則證書不可信。 哪種CA證書用作信任錨取決於客戶端：像Firefox這樣的瀏覽器帶有自己的信任庫，其他瀏覽器使用系統信任庫，其他客戶端使用另一個信任庫（即Java帶有自己的信任庫）。 請參閱SSL證書框架101：瀏覽器如何實際驗證給定服務器證書的有效性？ 更多細節。

現在，在自簽名的情況下，....因此，在這種情況下，我們在證書簽名期間使用了相同的公鑰/私鑰對，並且還為數據加密（Q3）共享了對稱密鑰？

對於自簽名證書，頒發者和證書的頒發者是證書本身，即，用於對證書進行簽名的私鑰與證書內部的公鑰匹配。 在使用RSA密鑰交換的情況下，此密鑰還涉及創建對稱密鑰（請參見上文）。

證書導入是否也會導入公鑰以驗證簽名正確（Q4）？

公鑰是證書的一部分（但私鑰不是）。 因此，證書導入也將隱式導入公鑰。

博客說，如果“受信任的根”證書中存在證書，則認為該證書有效。 這是否意味着瀏覽器不執行簽名驗證（Q5）？

根證書被認為是受信任的，因為它在本地信任存儲中，而不是因為它是由某些東西簽名的。 這就是為什么簽名驗證與根證書並不真正相關的原因。 為了正確地用作信任錨，SSL / TLS庫仍然經常要求根證書是正確的（自簽名）證書。