事件概述
2025年5月30日，Google 安全團隊透過官方部落格宣布：自2025年8月1日起，Chrome 139及後續版本將停止信任中華電信簽發的 TLS 憑證。這是台灣憑證基礎建設史上首次重大信任危機，影響超過10,000個網站，包括8,000個政府網站與2,000個企業網站。
此次撤銷信任的決策源於中華電信在憑證管理上的多次合規失敗，累積一年多的問題最終導致 Google 失去信心。本文將深入分析事件的前因後果、技術細節、影響範圍，以及對台灣數位基礎建設的啟示。
三大管理缺失
1. CAA 記錄檢查錯誤
問題描述：
2024年9月至2025年2月期間，中華電信進行大規模憑證遷移，將政府伺服器數位憑證管理中心（GTLSCA）的憑證轉移至 HiPKI OV TLS CA。在此過程中，中華電信未重新檢查 CAA（Certificate Authority Authorization）記錄，直接使用 GTLSCA 先前驗證的 DCV（Domain Control Validation）資料批次簽發新憑證。
什麼是 CAA？
CAA（憑證授權機構授權）是一種 DNS 記錄，允許網域擁有者指定哪些憑證授權機構可以為該網域簽發憑證。CA 在簽發憑證前應檢查網域的 CAA 記錄，確認自己是否獲得授權。
檢查 CAA 記錄的方式：
# 使用 dig 查詢 CAA 記錄
dig CAA example.com
# 使用 host 查詢
host -t CAA example.com
# 範例輸出：
# example.com has CAA record 0 issue "letsencrypt.org"
# example.com has CAA record 0 issuewild "letsencrypt.org"
影響規模：
- 時間：2024年9月4日 – 2025年2月26日
- 撤銷憑證數：11,860張
- 實際安裝使用：僅24張（測試用途）
- 通報時間：2025年3月1日（Chrome Root Program）
根本原因：
因為 GTLSCA 與 HiPKI OV TLS CA 都由中華電信管理，團隊誤以為可以共用驗證資料，忽略了 CAA 記錄是針對特定 CA 的授權機制。這違反了 CA/Browser Forum Baseline Requirements 關於憑證簽發前必須驗證 CAA 記錄的規定。
2. 延遲提交年度報告
問題描述：
中華電信的 GTLSCA 未在期限內提交2023年度的 CCADB（Common CA Database）自我評估報告，即使經過多次提醒仍未完成。
提醒時間軸：
- 2023年9月：首次提醒
- 2024年3月：第二次提醒
- 2025年1月：第三次提醒
- 最終：仍未提交完整報告
CCADB 是什麼？
CCADB（Common CA Database）是 Mozilla、Microsoft、Google、Apple 等瀏覽器廠商共同維護的憑證授權機構資料庫。所有受信任的 CA 必須定期提交自我評估報告，說明其合規狀態、稽核結果、政策變更等資訊。
為何重要？
年度報告是 CA 透明度與問責制的核心機制。延遲提交顯示：
- 內部流程管理不善
- 對合規要求的重視程度不足
- 缺乏有效的期限追蹤機制
3. 合規時程延遲與其他違規
EKU（Extended Key Usage）設定錯誤：
- 時間：2023年9月15日起（BR v2.0.0 生效日）
- 影響憑證數：約6,450張
- 問題：憑證的 EKU 擴充用途設定不符合規範
- 撤銷要求：CA/Browser Forum 要求5天內撤銷
- 實際情況：中華電信無法在期限內完成撤銷
SubjectDN 重複欄位：
- 發現時間：2024年9月
- 影響憑證數：247張
- 問題：憑證的 SubjectDN 中包含兩個 localityName 值
合規程序調整延遲：
中華電信未能在 Chrome 新政策要求的時間內調整內部程序，雖然後來完成調整，但已造成信任損失。
Google 撤銷信任的技術實作
使用 SCT 機制
Google 採用基於 SCT（Signed Certificate Timestamp，簽章憑證時間戳記）的不信任機制，而非直接移除根憑證。
技術細節：
- 判斷依據：憑證中的 SCT 時間戳記
- 截止時間：2025年7月31日 23:59:59 UTC
- 影響範圍：SCT 時間在截止日期後的憑證將觸發安全警告
- 生效版本：Chrome 139（2025年8月1日）
受影響的根憑證：
1. ePKI Root Certification Authority
O=Chunghwa Telecom Co., Ltd.
C=TW
2. HiPKI Root CA - G1
CN=HiPKI Root CA - G1
O=Chunghwa Telecom Co., Ltd.
C=TW
測試與覆寫選項
測試命令（Chrome 128+）：
# 模擬 SCT 不信任限制
chrome --test-crs-constraints=$SHA256_HASH:sctnotafter=$EPOCH_TIMESTAMP
# 範例：
chrome --test-crs-constraints=
"76E27EC14FDB82C1C0A675B505BE3D29B4EDDBBB5C609BA6FCC17E075B5C14BD:
sctnotafter=1722470399"
企業覆寫選項：
企業可透過 GPO（Group Policy Object）或平台特定的信任設定，明確信任受影響的憑證，覆寫 SCT 限制：
方法1：Windows GPO
Computer Configuration > Policies > Windows Settings >
Security Settings > Public Key Policies > Certificate Path Validation Settings
方法2：macOS Keychain
將憑證加入系統 Keychain 並設為「永遠信任」
方法3：Linux ca-certificates
將憑證複製至 /usr/local/share/ca-certificates/ 並執行 update-ca-certificates
影響範圍與實際案例
受影響網站統計
- 總計：超過10,000個網站
- 政府網站：8,000+（中央與地方機關、學校）
- 企業網站：2,000+
- 特殊案例：連中華電信自家網站的憑證都需更換
使用者看到的錯誤訊息
2025年8月1日起，使用 Chrome 瀏覽器訪問仍使用中華電信憑證的網站時，將看到以下警告：
您的連線不是私人連線
攻擊者可能會嘗試從 example.com 竊取您的資訊
（例如：密碼、訊息或信用卡資料）。
NET::ERR_CERT_AUTHORITY_INVALID
檢查網站是否受影響
方法1：使用 OpenSSL 檢查憑證簽發者
# 檢查憑證詳細資訊
openssl s_client -connect example.com:443 -showcerts < /dev/null 2>/dev/null |
openssl x509 -noout -text | grep -A 2 "Issuer"
# 若輸出包含 "Chunghwa Telecom"，表示受影響
# Issuer: O=Chunghwa Telecom Co., Ltd., CN=ePKI Root Certification Authority
方法2：檢查 SCT 時間戳記
# 檢查憑證的 SCT 擴充
openssl s_client -connect example.com:443 < /dev/null 2>/dev/null |
openssl x509 -noout -text | grep -A 10 "CT Precertificate SCTs"
# 若 SCT timestamp 在 2025-07-31 之後，Chrome 139+ 將不信任
方法3：線上工具
- SSL Labs: https://www.ssllabs.com/ssltest/
- 查看 “Certification Paths” 段落的簽發者資訊
後續處置與時程
中華電信的回應
- 暫停簽發：自2025年8月1日起完全暫停 TLS 憑證簽發
- 既有憑證：7月31日前簽發的憑證不受影響，仍有效一年
- 恢復目標：預計2026年3月前重新取得 Chrome 預設信任
- 改善措施：強化內部流程、加強人員訓練、改善合規追蹤系統
受影響組織的應對建議
立即行動（2025年7月前）：
- 盤點現有憑證
- 列出所有使用中華電信憑證的網站與服務
- 檢查憑證到期日與簽發者
- 選擇替代 CA
- 國際選項：Let’s Encrypt、DigiCert、Sectigo、GlobalSign
- 台灣選項：政府憑證管理中心 GCA（政府網站）
- 測試替換流程
- 在測試環境驗證新憑證
- 確認應用程式相容性
- 規劃遷移時程
- 優先處理高流量網站
- 安排維護時段進行替換
長期改善：
- 建立憑證管理機制
- 使用憑證管理工具（如 Certbot、cert-manager）
- 設定到期提醒
- 自動化更新流程
- 實作監控機制
- 監控憑證到期時間
- 追蹤 CA 合規狀態
- 設定憑證透明度日誌（CT Log）監控
- 多元化 CA 策略
- 避免單一依賴
- 考慮使用多個 CA 作為備援
對台灣數位基礎建設的啟示
1. 合規不是選項，而是必要條件
國際憑證生態系統建立在嚴格的合規要求上。即使是國家級電信公司，一旦違反規範，仍會被撤銷信任。台灣的 CA 業者必須：
- 建立完善的合規追蹤系統
- 投資專業人員訓練
- 定期進行內部稽核
- 積極參與國際標準制定
2. 政府數位服務的脆弱性
8,000個政府網站受影響，顯示台灣政府數位服務對單一 CA 的高度依賴。建議：
- 建立政府憑證管理中心 GCA 作為備援
- 制定政府網站憑證管理規範
- 定期演練 CA 失效情境
- 提升資訊人員對憑證管理的認知
3. 憑證管理的專業門檻
此次事件凸顯憑證管理的複雜性：
- CAA 記錄檢查的重要性
- 不同 CA 間資料不可共用
- 合規報告的嚴格時程
- 撤銷程序的時效要求
組織需要：
- 指派專責人員負責憑證管理
- 建立標準作業程序（SOP）
- 使用自動化工具降低人為錯誤
4. 透明度與信任的關係
憑證透明度（Certificate Transparency）機制讓所有憑證簽發行為都有跡可循。中華電信的問題之所以被發現，正是因為 CT Log 的監控機制。這提醒我們：
- 透明度是建立信任的基礎
- 隱藏問題只會讓問題更嚴重
- 主動揭露與改善才是正確態度
開發者與企業的行動指南
檢查清單
網站管理者：
# 1. 檢查目前使用的憑證簽發者
openssl s_client -connect your-domain.com:443 -showcerts < /dev/null 2>/dev/null |
openssl x509 -noout -issuer
# 2. 檢查憑證到期日
openssl s_client -connect your-domain.com:443 < /dev/null 2>/dev/null |
openssl x509 -noout -dates
# 3. 檢查 SCT 時間戳記
openssl s_client -connect your-domain.com:443 < /dev/null 2>/dev/null |
openssl x509 -noout -text | grep -A 10 "CT Precertificate SCTs"
應用程式開發者：
- 實作 SSL Pinning 的風險評估
- 若應用程式使用 SSL Pinning 綁定中華電信憑證，需緊急更新
- 考慮改用公鑰 Pinning 而非憑證 Pinning，提升彈性
- 參考：在 Android 中實現 SSL Pinning 與自定義信任鏈的完整指南
- 更新應用程式中的信任錨點
- 若應用程式內嵌信任的根憑證清單，需發布更新
- 建議使用系統信任庫而非自定義清單
- 測試憑證變更影響
- 在開發環境模擬新憑證
- 驗證 API 連線、第三方服務整合
自動化工具建議
憑證管理工具：
# 1. Certbot (Let's Encrypt)
sudo apt install certbot
sudo certbot certonly --webroot -w /var/www/html -d example.com
# 2. acme.sh (支援多種 CA)
curl https://get.acme.sh | sh
acme.sh --issue -d example.com -w /var/www/html
# 3. cert-manager (Kubernetes)
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.13.0/cert-manager.yaml
監控腳本範例：
#!/bin/bash
# 檢查憑證到期時間並發送警告
DOMAIN="example.com"
DAYS_WARNING=30
# 取得憑證到期日
EXPIRY_DATE=$(openssl s_client -connect $DOMAIN:443 < /dev/null 2>/dev/null |
openssl x509 -noout -enddate | cut -d= -f2)
# 轉換為時間戳記
EXPIRY_TIMESTAMP=$(date -d "$EXPIRY_DATE" +%s)
CURRENT_TIMESTAMP=$(date +%s)
DAYS_REMAINING=$(( ($EXPIRY_TIMESTAMP - $CURRENT_TIMESTAMP) / 86400 ))
# 檢查是否需要警告
if [ $DAYS_REMAINING -lt $DAYS_WARNING ]; then
echo "警告：$DOMAIN 的憑證將在 $DAYS_REMAINING 天後到期！"
# 發送通知（email、Slack 等）
fi
# 檢查簽發者
ISSUER=$(openssl s_client -connect $DOMAIN:443 < /dev/null 2>/dev/null |
openssl x509 -noout -issuer)
if echo "$ISSUER" | grep -q "Chunghwa Telecom"; then
echo "警告：$DOMAIN 使用中華電信憑證，需盡快更換！"
fi
常見問題
Q1：我的網站在7月31日前取得的憑證還能用嗎？
A：可以。7月31日前簽發的憑證不受影響，仍可正常使用直到到期（最長一年）。問題在於憑證到期後，無法再從中華電信取得新憑證，必須更換 CA。
Q2：除了 Chrome，其他瀏覽器會跟進嗎？
A：目前 Google 正式宣布 Chrome 的撤銷決定。Edge（基於 Chromium）很可能跟進。Firefox 與 Safari 維護各自的根憑證清單，需關注 Mozilla 與 Apple 的後續公告。從歷史經驗來看，主要瀏覽器對 CA 合規問題的立場一致，跟進機率高。
Q3：使用 Let’s Encrypt 等免費憑證是否足夠？
A：對大多數網站而言，Let’s Encrypt 提供的 DV（Domain Validation）憑證已足夠。但有些情境可能需要付費 CA：
- 需要 OV/EV 憑證：顯示組織名稱、綠色網址列（EV）
- 需要保固：付費 CA 通常提供數位憑證保險
- 需要技術支援：付費 CA 提供專業客服
- 內部政策要求：某些組織規定不得使用免費憑證
Q4：如何避免未來再次發生類似問題？
A：建議採取以下措施：
- 多元化 CA 策略：不依賴單一 CA，準備備援方案
- 自動化管理：使用 Certbot、cert-manager 等工具自動更新憑證
- 監控機制：設定到期提醒、追蹤 CA 合規狀態
- 定期演練：每年至少一次演練 CA 切換流程
- 文件化流程：建立完整的憑證管理 SOP
Q5：這次事件對 Android/iOS 應用程式有影響嗎？
A：有影響，特別是實作 SSL Pinning 的應用程式：
- 使用系統信任庫：Android 7.0+ 與 iOS 會跟隨作業系統更新，最終也會撤銷對中華電信憑證的信任
- 實作 SSL Pinning：若應用程式直接 Pin 中華電信憑證或公鑰，需緊急發布更新
- 自定義信任鏈：若應用程式使用自定義的根憑證清單，需移除中華電信憑證
建議開發者：
- 檢查應用程式是否實作 SSL Pinning
- 若有，改用公鑰 Pinning 並 Pin 伺服器憑證的公鑰，而非 CA 根憑證
- 定期更新應用程式的信任設定
總結
中華電信憑證撤銷事件是台灣數位基礎建設的重要警訊。這次危機凸顯：
- 合規管理的重要性：憑證生態系統建立在嚴格的規範與透明度上
- 單點依賴的風險：政府與企業不應過度依賴單一 CA
- 專業人才的需求：憑證管理需要專業知識與持續學習
- 自動化的必要性：人工管理容易出錯，自動化是趨勢
- 危機處理的能力：組織應具備快速應變的能力與流程
受影響的組織應立即展開憑證盤點與遷移規劃，在2025年8月前完成替換。長期而言，台灣需要建立更健全的憑證管理生態系統，包括政府支持的備援 CA、專業人才培育、以及業界最佳實踐的推廣。
這次事件也提醒所有開發者與企業：數位信任不是理所當然的，需要持續的努力與投資來維護。