信任鏈的基本結構
2026 年 10 月 21 日，InfoQ 刊出 Chris Swan 的報導，揭露憑證機構 eMudhra 有八張中繼憑證機構（intermediate Certificate Authority，以下稱中繼 CA）憑證的私鑰外洩。要理解這件事為何不只是單一廠商的疏失，得先看公開金鑰基礎建設（Public Key Infrastructure，PKI）的運作方式。瀏覽器與作業系統在出廠時會預先信任一批根憑證機構（root CA），根 CA 通常不會直接簽發每一個網站的憑證，而是先簽署一層中繼 CA，再由中繼 CA 簽發實際供網站使用的伺服器憑證。這條從根 CA 到中繼 CA、再到終端憑證的路徑，就是所謂的信任鏈。中繼 CA 的設計原本是為了營運安全：根 CA 的私鑰可以離線保管，日常大量簽發交給中繼 CA 處理。但這也代表，任何持有中繼 CA 私鑰的人，都能替任何網域簽出一張在信任鏈上看起來完全合法的憑證。八張中繼 CA 憑證的私鑰外洩，等於在信任鏈上留下八個可以直接繞過的入口。
私鑰的問題：不是亂度不夠，而是根本沒有亂度
這起事件最關鍵的細節，是沒有證據顯示 eMudhra 遭到入侵。外洩的私鑰看起來不是被偷走，而是在生成時就出了問題。正常的私鑰應該是夠大的隨機數，讓攻擊者無法窮舉；但這八張憑證的私鑰除了最後一個位元組之外全部是零，而最後一個位元組只會是 4、56、66、115、155、156、230 或 237。這種金鑰的搜尋空間小到可以逐一枚舉，對應的公開金鑰也能輕易推導出來。當這些公開金鑰出現在實際運作的中繼 CA 上，原本只是亂度（entropy）不足的私鑰，就變成真正的洩漏。換句話說，問題不是金鑰不夠隨機，而是它幾乎完全沒有隨機性。
發現過程帶有一點戲劇性。根憑證存放區的事件報告把發現者記為「Wayne」，他提交了一個名為 proof.zip 的檔案，附上的說明只有「we have a problem here」。之後 Dennis Jackson 建立了事件摘要網站，網域是 emudhra.we-have-a-problem.com，該網站本身使用 LetsEncrypt 憑證。八張受影響的憑證中，六張用於傳輸層安全性（Transport Layer Security，TLS），受到 Apple、Chrome、Microsoft 與 Mozilla 的根憑證信任計畫信任；另外兩張用於程式碼簽章，受 Microsoft 信任。這個分布說明影響範圍不限於瀏覽器連線，也觸及軟體發行與更新的簽章驗證。
瀏覽器能快速封鎖，其他軟體卻未必
瀏覽器的反應相對迅速。它們透過背景撤銷封鎖清單（revocation blocklists），把受影響的中繼 CA 標記為不可信任；這類清單在背景更新，可以在使用者連線之前就完成阻擋，速度快且能精準針對特定中繼 CA。然而，大多數依賴網頁公開金鑰基礎建設（Web PKI）的軟體，並沒有過濾中繼 CA 的機制。對這些系統來說，只要根憑證還在信任清單裡，底下衍生出來的中繼 CA 就會被一併接受。
為了阻擋來自這些中繼 CA 的偽造憑證，許多專案選擇把 emSign ECC Root CA - G3 從信任根中移除。這個做法能有效切斷整條有問題的鏈，但也帶來附帶損害：所有由該根憑證簽發、原本完全合法的憑證，會跟著失效。實務上，curl 專案整理維護的 Mozilla cacerts 檔案被廣泛沿用，包括 Linux 發行版與許多程式語言的 TLS 實作。Arch、Debian、Gentoo、Fedora 與 Ubuntu 的 ca-certificates 套件都已更新；Electron、Go、pip、Python certifi、rustls-webpki、Rust webpki-roots 與 uv 也陸續跟進。這些更新需要時間傳播到所有使用地點，沒有主動修補的系統，包括已經終止支援的版本，會繼續處於風險之中。
有些語言與框架已經不再內建信任根，而是交給開發者決定要依賴系統根憑證，或自行維護清單。Dart 從 2026 年 8 月發布的 3.13 版起，不再內嵌 cacerts 檔案；熱門的 Flutter 跨平台框架正是使用 Dart。依賴系統根憑證的好處是更新速度較快，應用程式不必跟著改版；開發者自行選擇信任根，則可以把信任範圍縮小到已知的 CA。但反過來說，許多應用程式把 cacerts 檔案埋在發行檔內部，這些應用會繼續信任已經淪陷的中繼 CA，形成難以察覺的盲點。
mTLS、CAA 與憑證透明度各自的缺口
憑證不只用在伺服器身分驗證，也用在用戶端認證，尤其是相互 TLS（mutual TLS，mTLS）。如果應用程式信任 Web PKI 的根憑證，偽造憑證就可能成為繞過認證的手段。SSLMate 創辦人 Andrew Ayer 指出，真正該感到不安的，是那些用 WebPKI CA 來做 mTLS 或 TLS 用戶端認證的系統：攻擊者可以直接鑄造一張憑證，通過 mTLS 端點的驗證，而端點很可能根本不知道中繼 CA 已被撤銷，整個過程不需要 BGP 劫持或其他網路攻擊。Chrome 計畫禁止 clientAuth 延伸金鑰用途（Extended Key Usage，EKU），但期限已經延後；Ayer 也提到有六個服務把 mTLS 驗證器改成接受 serverAuth EKU 來取代 clientAuth，顯示這種被視為不好的做法仍然存在。
另一道原本預期能擋住濫發的防線，是網域名稱系統的憑證機構授權（DNS Certificate Authority Authorization，CAA）記錄。CAA 的設計是要求 CA 只能替記錄中列出的網域簽發憑證，但偽造者不會遵守這項檢查。加上 CAA 的普及率偏低，即使許多熱門網站也沒有設定，因此它在這次事件中能提供的保護相當有限。
憑證透明度（Certificate Transparency，CT）則提供另一種思路：把憑證簽發紀錄放進分散式帳本，讓用戶端可以檢查某張憑證是否被正確記錄，並拒絕沒有出現在日誌裡的偽造憑證。RFC6962 與 RFC9162 分別定義了 CT 與 CT 2.0。更早之前，Moxie Marlinspike 在 2011 年 Black Hat 大會提出 Convergence，設想用分散式的憑證觀察系統來判斷有效性，而不是只依賴 CA 與信任根；這個構想沒有獲得足夠採用。CT 雖然試圖達成類似目標，但在瀏覽器之外的使用並不普遍，因此在這類事件中能發揮的作用仍然受限。
這不只是單一事件，而是信任模型的壓力測試
把視角拉遠，問題的根源在於信任鏈的規模。典型的根憑證捆綁裡有數百個 CA，底下繼承信任的中繼 CA 則有數千個；其中任何一個都能替任何網域簽發看起來合法的憑證。只有當信任錨被更新，信任鏈才會真正斷開；沒有修補的系統會一直暴露在風險中。這起事件也呼應 Spice Labs 創辦人 David Pollak 在 Viktor Peterson 播客「Post-Quantum Cryptography: Rethinking Trust Before the Clock Runs Out」中提出的情境：如果熱門根 CA 的私鑰外洩，會發生什麼事？隨著往「Q day」逼近，CA 仍錨定在 RSA 與橢圓曲線密碼學（Elliptic-curve cryptography，ECC）等古典演算法上，這個問題只會更受關注。
這也解釋了為什麼 SSL/TLS 憑證的壽命要在 2029 年縮短到 47 天。憑證壽命越短，系統越容易汰換成使用新信任錨的憑證，降低舊錨點出事後的影響時間。Let's Encrypt 在「A Post-Quantum Future for Let's Encrypt」中進一步提出梅克爾樹憑證（Merkle Tree Certificates，MTCs），作為直接使用 ML-DSA-44 等後量子演算法簽章的替代方案。這種做法除了在握手時減少傳輸量，也讓金鑰洩漏的影響更容易被控制。
對實際維運而言，這次事件留下的教訓不是記住那八個位元組值，而是重新清點系統裡的信任根：它們從哪裡來、由誰維護、更新路徑是否暢通，以及那些不會自動更新的應用程式與裝置，是否已經被納入管理。信任不是設定一次就永久有效的狀態，而是一條需要持續維護的鏈條。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。