什麼是SSL預證書？

預驗證是用作證書透明度（CT）一部分的特殊類型的SSL證書。 預先證書與常規SSL證書不同，因為它們不是（也不可以）用於驗證伺服器或形成經過身份驗證的連接（例如HTTPS連接）。它們的唯一目的是允許證明證書已被記錄以直接嵌入到證書中。顧名思義，預認證出現在正式證書之前。而預證書幾乎很少暴露給最終用戶，也就是說你可能收到了預證書但從不知道它的存在。

預證書在證書透明度RFC中定義。本文將用簡單的語言解釋什麼是預先證書，如何使用它們以及它們的工作機制。

為什麼需要預證書？

預證書的存在是為了允許將證書透明度數據直接嵌入到最終證書中。

預驗證是將證明提交到證書透明度日誌（SCT）的證書的幾種方式之一。 預處理的優點是允許將CT數據嵌入SSL證書本身，而不是作為單獨的數據提供（其他方法要求在握手期間將SCT作為單獨的文件發送，與OCSP Stapling類似）。

CT日誌需要能夠為該證書的數據生成一個有效的簽名（SCT），但是CA還需要日誌中的SCT才能創建最終的證書。 於是需要預證書來解決這個問題，它允許日誌生成正確的簽名，而不需要最終的證書。

以下是需要用到預證書的場景：

1.證書頒發機構（CA）將向客戶簽名並頒發證書。他們需要使其符合瀏覽器的CT策略，因此他們需要將證書提交到CT Log。

2.CA對如何提供證書已被記錄的證據有不少選擇。如果他們想直接將該證明嵌入證書，他們將需要使用預認證。

3.在CA簽署最終證書之前，他們首先創建一個預認證，其中包含相同的數據，但格式化為特定方式，以使其不被視為有效的SSL證書。

4.CA將預認證提交到CT日誌並接收SCT（簽名證書時間戳）。這是一個由日誌簽署的文件，可用於密碼證明客戶端證書已被記錄。

5.CA發布最終證書，SCT嵌入其中。

6.終端用戶可以部署他們的證書，並證明他們的證書中包含它們的CT合規性。這是包含SCT的最佳方式。

當你搜索證書透明度日誌時，可能會遇到預認證，但不能檢查關聯的（有效的）證書。 這是因為CA不需要將後續證書提交到日誌。 即使預先認證不被客戶視為有效，但是仍然保留相同的發行標準。 CT RFC規定，「預認證的錯誤被認為等於最終證書的錯誤」。

預證書如何運作？

預證書不同於普通證書的點在於它使用X.509 v3格式的擴展名的數據欄位區。擴展為X.509格式提供了靈活性，並允許採用新功能，而不需要新版本的格式。

預證書包含一個「有毒的擴展」。是的你沒看錯，這個擴展有毒！之所以這麼稱呼它是因為該擴展十分關鍵還不支持客戶端。如果它沒有被正確解析，那麼正式證書就要GG（被判無效）了。而當客戶端遇上預認證，十之八九都會把它認作無效。「有毒」擴展的存在可以說是常規證書和預證書之間唯一的區別了。

毒性擴展使用一種獨一無二的OID：1.3.6.1.4.1.11129.2.4.3。OID又稱對象標識符，是分配給某些目的並用於提供計算機可解析格式的標準化字元串。例如，您可以查看該OID號碼，並看到它已被分配了以下目的：「證書透明度預認證毒藥擴展（poison extension）」。其他OID（如1.3.6.1.5.5.7.48.1）用於SSL證書中以指示該證書的OCSP URL。

舉個栗子，如果你在Windows中下載並打開一個預認證，它將看起來與常規SSL證書非常相似。 但是，在Windows「證書查看器」的「常規」窗格中，您將注意到它將顯示為「證書包含未標識為」關鍵「的擴展名。」在「詳細信息」中，您會看到底部附近列出的毒藥擴展名（查找OID）。

因為這個擴展是存在的，Windows將預認證視為無效。 這樣可以防止在使用SSL證書的情況下使用SSL，例如在HTTPS連接中。 在macOS上，證書查看器會說「不能使用此證書（無法識別的關鍵擴展）」。

在證書透明度協議（仍在開發中，RFC6962）的2.0版本中，預認證的格式將從X.509更改為CMS（加密消息語法）。 這意味著預製證的技術格式和編碼將會大大改變，並且將不再是與常規SSL證書相同的格式。也就是說，當部署CT 2.0時將不會再有毒藥擴展，因為不需要區分預密碼和有效的X.509 SSL證書。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！