關於 TLS 驗證過程的說明
我正在閱讀這篇文章，試圖了解 TLS 驗證和信任鏈的工作原理。在這篇文章中，我遇到了一個我不確定我是否理解的部分。
在瀏覽器如何驗證證書的簡化描述中，您有以下內容：
客戶端是一個瀏覽器，為了便於解釋，它必須完成兩個過程來驗證簽名。第一個過程是獲取證書底部的簽名並使用 CA 的公鑰對其進行解密。此公鑰來自 CA 的中間證書，該證書應在 TLS 握手開始時的連接期間由伺服器提供。這告訴我們，如果 CA 的公鑰可以解密它，那麼 CA 的私鑰肯定已經加密了它。這意味著它肯定來自有問題的 CA，因為只有他們擁有私鑰。第二個過程是瀏覽器計算自己的 Pre-Certificate 雜湊，與簽名中儲存的雜湊進行比較，並確定它們是否相同
但不確定這部分是否正確：
第一個過程是獲取證書底部的簽名並使用 CA 的公鑰對其進行解密。此公鑰來自 CA 的中間證書，該證書應在 TLS 握手開始時的連接期間由伺服器提供。
說公鑰由伺服器傳遞的部分是否正確？我會假設瀏覽器在此步驟中使用預先安裝的 CA 公鑰。
文章錯了嗎？還是我做錯了？
文章有誤，但不存在。是上一句不正確。“第一個過程是獲取證書底部的簽名，並使用 CA 的公鑰對其進行解密。” 強調我的：簽名不是加密，解密它們不是客戶端所做的，客戶端驗證簽名。這與您的問題無關，但重要的是不要將加密/解密與簽名/驗證混淆，因為這樣做會導致重大的安全問題。這種混淆只有在使用 RSA 時才是真正可能的，許多其他公鑰系統一開始就沒有任何真正的加密/解密概念。像這樣混淆基本術語是停止閱讀任何有關公鑰加密的文章的好理由。混淆簽名和加密就像混淆加法和除法：模糊相關，有點交換（簽名更接近 RSA 中的解密，但仍然不同），並且通常表明文章不是由任何有能力的人編寫的。
為了回答您的問題，伺服器會發送一系列證書。鏈中的每個證書都包含一個公鑰、一個名稱（伺服器的域、CA 的組織名稱）、一些額外的資訊以及涵蓋所有這些的簽名。簽名由私人創建鏈中下一個證書的密鑰，並且可以通過該證書的公鑰進行驗證。一端是網站的證書，它不簽署任何進一步的證書，另一端是“根”證書。這個“根”是瀏覽器預裝的唯一東西。瀏覽器可以驗證鏈中的命名根是否具有預安裝的證書。然後瀏覽器可以驗證下一個證書的簽名是由那個根創建的，等等。如果所有簽名都經過驗證，則可以信任最終的網站證書屬於該域的所有者。
實際上，這些證書鏈可能很短。許多 CA 被信任為這些鏈的根。例如，此站點（此時）有一個 *.stackexchange.com 的證書，該證書由 Let’s Encrypt R3 證書（Let’s Encrypt 是一個 CA）簽名，而該證書又由 Internet 安全研究組 ISRG Root X1 簽名證書（ISRG 是執行 Let’s Encrypt CA 的組織）。瀏覽器直接信任 ISRG Root X1，並驗證它是否簽署了 Let’s Encrypt R3 證書。然後他們驗證 Let’s Encrypt R3 簽署了 *.stackexchange.com 的證書。鏈中只有 3 個級別。