10 月 20 日，Cloudflare 與 Google 先後公告：印度憑證機構 eMudhra 有八張中繼 CA 憑證的私鑰是用「亂數不夠亂」的方式產生，任何人都可能偽造任何網域的 HTTPS 憑證。Chrome 幾個小時內就封鎖了，但你的容器映像、API 用戶端、cloudflared 與 mTLS 設定，不會自己更新。還有一個期限：使用 emSign ECC Root CA - G3 憑證鏈的網站，要在 10 月 27 日前換憑證。
想像一下，全城的鎖匠工會發現，有八位師傅打的萬能鑰匙模具，其實是用骰子決定齒形，而且骰子只有兩面。結果任何人都能複製出一把「看起來完全合法」的鑰匙，打開任何一家店的門。
這不是笑話，這大概就是這週 HTTPS 世界發生的事。
網址列上那個小鎖頭，背後靠的是一條信任鏈：網站的憑證由中繼憑證機構簽發，中繼憑證再由根憑證背書，而瀏覽器和作業系統裡內建一份「我信任這些根憑證」的清單。只要鏈上任何一環的私鑰被人拿到，攻擊者就能替任何網域簽出一張「看起來是真的」憑證。
發生了什麼事？
依 Cloudflare 10 月 20 日的公告，Cloudflare 在 10 月 19 日約 17:00 UTC（台灣時間 20 日凌晨 1 點）得知，與 eMudhra 八張中繼憑證相關的私鑰已經外洩。這些憑證受到瀏覽器、作業系統以及 Cloudflare 內部系統的廣泛信任。因為金鑰本身強度不足，攻擊者可以偽造任何網域的憑證，冒充伺服器來攔截或竄改流量。Cloudflare 直說這是「影響整個網際網路的嚴重資安事件」。
Google 的公告提供了更多細節：Chrome 根憑證計畫在 10 月 17 日 18:05 UTC 收到研究人員通報，這些私鑰是以「不足的隨機性」（弱熵）產生的。Chrome 在 19:45 UTC 完成驗證，並推出 CRLSet 更新，直接封鎖這些中繼憑證的公鑰。因為是用公鑰比對封鎖，Chrome 使用者不需要更新或重開瀏覽器就立即受到保護；Android 裝置則透過 Google Play 服務收到相同更新。
兩個好消息先講：
- Cloudflare 表示，安全審查沒有發現這個問題在 Cloudflare 服務上被實際利用。
- Google 表示，在封鎖之前，沒有任何串接到這些中繼憑證的 TLS 憑證被記錄到「憑證透明度」（Certificate Transparency，CT）日誌，所以偽造憑證無法用來攻擊會強制檢查 CT 的用戶端，包括 Chrome。
為什麼瀏覽器修好了，事情還沒完？
Cloudflare 在文末點出最關鍵的一句話：這次事件的衝擊「並不平均」。瀏覽器廠商只要撥一個開關就修好了，因為他們只需要更新一個應用程式，而且手上有 CRLSet 這種快速撤銷機制。
但你的系統不是只有瀏覽器。後端呼叫金流 API、Webhook 推送、排程去抓第三方資料、容器裡的服務互相連線，這些「非瀏覽器」的 TLS 連線，信任清單來自作業系統、語言執行環境、HTTP 函式庫，或你自己打包進映像檔的 CA 套件。它們不會因為 Chrome 更新就跟著變聰明。
Cloudflare 給開發者的建議只有一句：「往 SDK 底下看。」API 用戶端可能把憑證驗證交給 HTTP 函式庫、語言執行環境、作業系統或自訂設定，只更新 SDK 不一定會改變底層的信任政策。
有截止日的那一件事：10 月 27 日
如果你只記得一件事，請記這個。
Google 表示，為了保護不使用 CRLSet 的 Chrome 根憑證庫使用者，已決定把簽發這些中繼憑證的 emSign ECC Root CA - G3 移出 Chrome 根憑證庫，預計在美西時間 10 月 27 日（週二）上午對所有使用 Chrome 根憑證庫的裝置生效（台灣時間約 27 日深夜到 28 日凌晨），Canary、Beta 等測試頻道會更早。屆時，串接到這個根憑證的合法憑證也會在 Chrome 失效。Google 的原話是：使用該根憑證鏈的網站營運者「必須立即」向其他憑證機構取得新的 TLS 憑證。eMudhra 也承諾協助受影響客戶遷移。
台灣多數網站用的是其他憑證機構，但「多數」不等於「你」。花五分鐘確認一下，比週三早上被客戶打電話罵划算太多。
維運檢查清單：照著做就對了
以下依 Cloudflare 與 Google 的建議整理：
1. 先確認自己網站的憑證鏈。 用瀏覽器檢視憑證，或用 openssl s_client -connect 你的網域:443 -showcerts 看完整憑證鏈，確認根憑證不是 emSign ECC Root CA - G3。如果是，立刻換發。
2. 有用 Cloudflare Tunnel 的，升級 cloudflared 到 2026.10.2。 容器部署要更新並重新部署修正後的映像檔。WARP／Cloudflare One 用戶端也有對應版本，公司電腦請一併更新。
3. 檢查 mTLS 信任清單。 如果你有設定「用戶端憑證驗證」，檢查上傳的 CA 清單是否包含受影響憑證。
4. 來源伺服器的憑證設定。 使用 Cloudflare Full (strict) 或 Strict 模式的客戶，請檢查自訂來源憑證。Cloudflare 表示會讓 Automatic SSL/TLS 主動通知仍在使用這些被撤銷信任憑證的客戶。
5. 容器映像要重建，不是重開。 Cloudflare 提醒，更新信任清單、基礎映像之後，還要搭配重新載入、重啟或重新部署才會生效。基礎映像裡的 ca-certificates 套件是常被遺忘的角落；Cloudflare Containers 用戶也要檢查映像與相依套件。
6. 用「實際的連線路徑」驗證。 Mozilla 的 Dennis Jackson 整理了已修補套件清單和測試網站。但 Cloudflare 特別提醒：瀏覽器測試通過，不代表背景服務安全；curl 測試通過，也不代表用不同驗證器的應用程式安全。要從應用程式真正走的 TLS 路徑測。
7. 千萬不要「關掉驗證」來讓錯誤消失。 更新後若出現憑證錯誤，最省事的做法是加上 verify=false 之類的參數。Cloudflare 明講不要這樣做，那等於把這次更新要恢復的保護整個拆掉。
情境演練：一家連鎖餐飲的訂位系統（假設案例）
假設一家連鎖餐飲品牌的官網跑在 Laravel 上，前面掛 Cloudflare，後台用 cloudflared 把內部 POS 系統接出來，另外有排程每五分鐘呼叫第三方訂位平台和金流 API，全部跑在 Docker 容器裡。
這週該做的事：確認官網憑證鏈正常；把 cloudflared 升級到 2026.10.2 並重新部署；重建 PHP 容器映像，讓基礎映像的 CA 套件更新；重啟佇列 worker，確保新信任清單載入；最後從容器裡實際呼叫一次金流與訂位 API，確認連線正常、沒有人偷偷關掉驗證。
整套做完大概半天。比起事後解釋「為什麼顧客的訂位資料可能被中間人看光」，這半天非常便宜。
給網站業主與委外客戶的建議
- 問你的工程團隊或工作室三個問題：我們的憑證是哪家簽的？後端有哪些對外 API 連線？容器映像上次重建是什麼時候？答不出來，就是需要盤點的訊號。
- 把「信任清單更新」列進維運 SOP：Cloudflare 提到，業界正在發展像 upki 這類專案，讓信任清單能像 CRLSet 一樣快速更新撤銷資訊。在那天到來之前，定期重建映像是最實際的做法。
- 憑證不要只有一家能救：自動化憑證換發流程（例如 ACME），出事時換一家憑證機構只是改一行設定。
你可能會問
Q：我的網站沒有用 eMudhra，還需要做什麼嗎？ A：需要。風險不只是「你的憑證」，而是攻擊者可能偽造「任何網域」的憑證來騙你的伺服器。只要你的後端會連出去，信任清單就該更新。
Q：有人真的被攻擊了嗎？ A：截至公告，Cloudflare 沒有在自家服務發現實際利用；Google 表示封鎖前 CT 日誌沒有相關憑證紀錄。但不會強制檢查 CT 的用戶端仍有理論風險，這正是要更新信任清單的原因。
Q：Google 公告說「八張」，後面又提到「六張中繼憑證」，到底是幾張？ A：Google 原文前段寫八張，談 CT 時寫六張，原文未說明差異。Cloudflare 公告寫八張。我們依原文照錄，以官方後續說明為準。
Q：更新後一堆憑證錯誤怎麼辦？ A：找出是哪條連線、對方用的是哪個憑證鏈，請對方換憑證，或確認你的信任清單更新正確。就是不要關驗證。
結語：鎖頭會壞，但換鎖的速度可以練
這次事件的教訓不是「HTTPS 不可靠」，而是信任是一份會變動的清單，而你的系統裡有好幾份清單分散在各處。瀏覽器幾個小時就修好，是因為它們早就為「明天可能要撤銷某張憑證」做好準備。
你的伺服器也可以。從今天起，把重建映像、升級用戶端、檢查憑證鏈變成例行公事，下次再有鎖匠出包，你只需要喝口咖啡，按下部署鍵。
來源：8 eMudhra certificates are compromised. Here's what you need to know（Christopher Patton、Bas Westerbaan、Trishna、Jeremy Hartman，Cloudflare Blog，2026/10/20）。 延伸參考：Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates（Chrome and Android Security Teams，Google，2026/10/20）。