證書信任模型具體是如何工作的？
證書頒發機構（例如 VeriSign）和它的客戶（例如 foo.com）之間的整個架構是如何工作的。
我的瀏覽器如何知道 foo.com 沒有創建自己的證書，將“VeriSign”寫為頒發者，使用自己的私鑰對其進行簽名並將相應的公鑰寫入證書？
- 來自 foo.com（由 VeriSign 頒發）的證書中創建指向其證書頒發機構的連結的部分在哪裡？我想這肯定不是發行人（VeriSign）的字面意思。
我在這一點上停止了所有解釋，只是說“瀏覽器檢查它是否由 VeriSign 發布”。它是如何檢查的？是否有一種算法允許客戶端證書（例如 foo.com）也可以使用來自 VeriSign 的公鑰進行驗證並產生相同的雜湊？
- 來自foo.com的證書=> 客戶端使用來自 foo.com 的公鑰 => 接收雜湊 x
- 來自foo.com的證書=> 客戶端使用預安裝的 VeriSign 根證書中的公鑰）=> 相同的雜湊 x
這兩個證書如何相互關聯？
X.509 證書包含以下資訊：
- 證書所屬的主題的名稱。
- 主題的公鑰。該公鑰對應於私鑰。假定主題具有對此私鑰的獨占訪問權。
- 對證書頒發者的引用（例如 VeriSign 或其他一些證書頒發機構）。對於自簽名證書，頒發者將與主題相同。
- 更多欄位，例如證書的有效期、指定如何使用主題公鑰的擴展以及頒發者決定與證書關聯的各種資訊。
- DER 編碼所有上述資訊的數字簽名。
如果使用 RSA PKCS#1-v1.5 簽名算法，則 DER 編碼使用指定的摘要算法進行散列，該摘要是 PKCS#1-v1.5 簽名編碼的，並且對該編碼執行 RSA 私鑰操作使用發行者私鑰。
在伺服器端，伺服器將通過生成密鑰對、保持私鑰嚴格保密並將其主題名稱與公鑰一起發送給證書頒發機構來獲得伺服器證書。證書頒發機構驗證發送公鑰的實體是否也由提供的主題名稱正確標識。如果驗證成功，則頒發者頒發伺服器證書。
當客戶端使用 TLS（例如 HTTPS）連接時，伺服器將發送伺服器證書作為初始握手消息的一部分，並使用相應的私鑰生成或解碼握手的某些部分（例如簽署臨時公鑰，或解密密鑰傳輸消息），這樣只有擁有私鑰的實體才能完成握手並最終獲得與客戶端相同的共享密鑰。
客戶端，瀏覽器將有一個自簽名根 CA 證書列表，這些證書對應於瀏覽器製造商決定客戶端使用者應該信任的伺服器身份驗證的證書頒發機構。
當客戶端收到伺服器證書握手消息時，它通常會驗證數字簽名（使用頒發者證書中的公鑰），並且證書的主題名稱與它嘗試連接的 URI 的域部分匹配。還建議進行額外的驗證，例如證書有效期的離線驗證，以及證書撤銷狀態的線上或離線驗證。
如果伺服器證書籤出，客戶端從證書中提取公鑰並使用它來完成握手。如果握手成功完成並生成共享機密完整性密鑰，則伺服器從那裡發送的資訊將被驗證給客戶端。