Sectigo 網誌
甚麼是憑證固定？
憑證固定透過將伺服器憑證與已知副本比對，來驗證客戶端與伺服器之間的連線。不過，由於此機制複雜度高且存在風險，目前已大致被淘汰。本文會介紹其發展歷史、優點與風險。
甚麼是憑證固定？
憑證固定是一種用於驗證客戶端與伺服器連線的線上應用安全技術。Web瀏覽器透過此機制，讓客戶端應用程式將伺服器憑證與已知副本進行校驗。若兩者匹配，該連線就會被視為已授權（即「已固定」）。任何使用非固定憑證發起的安全連線請求都會被拒絕。
應用最常固定的是 X.509 憑證，不過僅固定受信任的證書頒發機構（CA）或公鑰也可實現此機制。此外，公鑰也可以單獨被固定，無需綁定至某一張憑證。
憑證固定最初是為防範中間人攻擊（MITM）而設計的。但由於其實現複雜度高、存在風險，目前已大致被淘汰，多數 Web 瀏覽器亦不再支援此機制。在憑證固定應用較為普遍的時期，大多數企業的固定實現方式都存在錯誤，繼而引發多宗 服務中斷。憑證固定的錯誤實現可能造成嚴重後果。因此，Sectigo 不建議使用憑證固定。
下文會詳細介紹此技術的發展歷史、運作原理、優點與風險。
此技術的發展歷史
2011 年，谷歌成為最早採用此技術的機構之一：Chrome 瀏覽器連接谷歌伺服器時，就啟用了 SSL/TLS 證書固定機制。Chrome 被設定為將域名連接至 Google.com 時，只接受當前已固定的憑證。如此一來，即使攻擊者透過欺騙手段取得受信任 CA 簽發的憑證，Chrome 仍會判定該憑證無效，從而拒絕連線。
儘管 Chrome、Firefox 等 Web 瀏覽器是最早實現此技術的應用，但其使用場景很快就得到拓展。不久後，物聯網（IoT）裝置、iOS 與安卓系統的流動應用程式，以及各類其他軟件應用都開始採用此技術防禦中間人攻擊。
但在快速迭代的網絡安全領域，SSL 證書憑證固定已被廣泛認為不再適用——它會帶來不可接受的 數碼證書敏捷性 成本，當中 HTTP 公鑰固定（HPKP）這個形式已被徹底棄用。
證書固定的運作原理是什麼？
從本質上而言，證書固定的原理十分簡單：這個流程會將需要建立連線的主機，與預先指定的證書、或是符合IETF X.509密碼學標準的伺服器公鑰進行關聯。一旦主機與證書之間的關聯建立完成，兩者的綁定關係就正式生效，也就是證書被固定到對應主機上。只有當伺服器提供的證書存在於固定證書集合中時，對應的客戶端連線或API呼叫才會獲准通過。
大多數情況下，經認可的固定證書會在應用程式開發階段就嵌入到應用程式內部。開發階段完成的固定操作會提升攻擊者破壞固定機制的難度，從而增加一層安全防護。證書也可以在應用程式首次發起連線時完成固定——這個流程稱為密鑰連續性。但使用密鑰連續性方案會帶來更高的風險敞口，因為在主機與應用程式的首次連線階段就有可能遭受攻擊。
證書固定的前提是客戶端與主機之間存在預先定義、預先建立的信任關係，且對應的協定與參數已被所有合法參與方知悉並認可。這種機制無需持續向體系內的組件發起查詢——例如無需持續向證書頒發機構（CA）請求證書狀態的最新更新。
哪些證書可以被固定？
應用程式擁有者可以自主選擇固定證書鏈中的哪一部分。最基本的要求是，信任鏈中至少要有一張證書完全由應用程式所屬的組織掌控。但一個十分常見的錯誤是僅固定證書鏈中的根證書。這種過度簡化的操作會留下安全漏洞：惡意攻擊者可以利用從同一家證書頒發機構（CA）簽發的其他證書獲得存取權限。因此，希望使用這項技術的應用程式開發者應當考慮固定證書鏈中的多張甚至全部證書，具體包括：
- 根證書： 根證書由受信任的證書頒發機構（CA）基於明確的證書驗證方法簽發，其公鑰、私鑰對通過複雜的密碼學演算法和哈希演算法生成。根證書由簽發它的根CA進行嚴格監控和保護。這意味著僅固定根證書本質上是信任了簽發該根證書的CA，以及從該根證書派生的所有中間證書對應的CA。
- 中間證書： 中間證書是葉子證書與根證書之間的銜接環節。一條證書鏈中至少要包含一張中間證書，單條鏈中也可以部署多張中間證書。僅固定中間證書的做法雖然可以實現，但並不推薦，因為這相當於你將全部信任托付給了對應的中間CA。
- 葉子證書： 葉子證書是證書鏈中最末端的證書。固定葉子證書幾乎可以確保證書完全匹配。葉子證書也被稱為終端用戶證書或終端實體證書，通常需要頻繁吊銷和更換，這就要求所有客戶端應用程式同步完成對應更新。
證書固定有哪些優勢？
對於希望將基於證書的認證與加密安全能力定制化直接嵌入到網頁應用程式和流動應用程式中的組織，證書固定可以提供更強的管控能力。理論上，證書固定會大幅提升網絡犯罪分子利用欺詐證書非法獲取應用程式或數據存取權限的難度，可防範以下風險場景：
- 無效證書簽發
- 證書頒發機構被入侵
- 中間人攻擊
證書固定存在哪些問題？
儘管SSL固定可以發揮安全效用，但它本身也存在較高風險。這種方式會給組織帶來成本高昂的證書管理難題，還可能影響用戶體驗。以下是使用該技術的組織可能面對的部分常見問題：
- 泄露密鑰的處置： 使用HPKP時，每張葉子證書通常會在應用程式中固定60天。而很多將葉子證書有效期設為60天的組織，並不會預留任何備份密鑰。一旦密鑰泄露，證書頒發機構（CA）必須吊銷該密鑰。在沒有可用備份密鑰的情況下，合法客戶端將無法再建立連線。密鑰泄露問題的解決往往難度高、成本大，還會耗費大量時間。
- 缺乏密碼敏捷性: 密碼學層面的變更發生頻率可能超出你的預期。當你或你的證書頒發機構（CA）不再信任現有密鑰，必須更換採用新密碼學演算法的證書時，就需要具備密碼敏捷性。由於證書固定會將證書要求硬編碼到應用程式中，證書的任何變更都既需要更新證書本身，還需要向應用程式推送更新修補程式。軟件更新的落地存在難度，尤其是在時間緊張的情況下，而未安裝最新版應用程式的客戶端可能無法存取應用程式，或是會收到應用程式連線不安全的警告。
- 證書吊銷： 證書頒發機構（CA）能夠且確實會吊銷證書. 證書吊銷可能由多種場景觸發。例如，審計過程中發現的問題就可能啟動吊銷流程。證書頒發機構（CA）可能在幾乎無提前預警的情況下被要求執行吊銷，這類事件未必能匹配您的開發規劃節奏。與密碼演算法變更的情況類似，您可能需要倉促緊急更新軟件，才能保障用戶可正常存取、或避免出現安全警告。
證書固定的替代方案
儘管並無與證書固定完全一一對應的替代方案，但目前已有多項技術可實現相同的安全目標。最常用的替代方案是證書透明度（CT）。這是一套用於監控及審計證書頒發機構（CA）簽發的所有公開SSL/TLS證書的開放框架。當證書頒發機構（CA）簽發公開信任的SSL/TLS證書時，會將證書詳情提交至證書透明度日誌。這些日誌可公開訪問，讓瀏覽器能夠驗證證書的簽發流程是否合規。各機構亦應監控CT日誌，核對指向自身域名的證書簽發情況。
此外，自動化證書生命週期管理（CLM）是確保需認證的證書在全部生命週期階段中時刻保持安全、處於最新狀態的理想方案：涵蓋申請與註冊、簽發與部署、使用與監控、到期與續期，以及吊銷全流程。了解這款兼容多CA的Sectigo 證書生命週期管理平台.
您還可以收聽我們的 Root Causes 播客，深入了解證書固定的相關知識、其誕生背景，以及為何現時幾乎所有開發者都應避免使用證書固定。