作者:
ZooseWu (N5)
2025-06-02 19:42:22※ 引述《ZooseWu (動物園 公告)》之銘言：
: https://www.facebook.com/share/p/16b3Fdu8nH/
: 中華電信憑證有問題
: google 叫他們更新又藉口一堆
: 問問題一問三不知 前後反覆 回應中還包含違反規章的內容
: 一氣之下 google 就決定把中華發的憑證視為不安全
找到一篇比較詳細的講解
我只能說活該
TL;DR
最一開始是發生在2024-03-19的 https://bugzilla.mozilla.org/show_bug.cgi?id=1887096
主角是中華Government TLS CA (GTLSCA)，下或簡稱中華…但注意RootCA其實也是中華電信，GTLSCA的CA証書是由中華RootCA簽出來，交了給數位發展部，再交由中華日常營運，業務是簽發政府用的TLS証書。
GTLSCA自己發現X509v3 Extended Key Usage (EKU)標成了critical，但在TLS CA要遵守的TLS Baseline Requirement (BR) 2.0版 (2023-04-11)開始規定是不能標成critical的。過往的BR沒有規定能或不能是critical，看來是自由決定的。
我個人意見是這實際上沒有安全問題，標critical只會變更嚴。相容性嘛以前都這樣做，BR 2.0後也用了一年，要有問題早就出了問題。
TLS BR: https://cabforum.org/working-groups/server/baseline-requirements/documents/
但一開始這個incident reporting做得不好，一問三不知，什麼時候發現、怎樣發現、接下來什麼時候修好、証書怎樣換等等都問下一才擠牙膏講出來，別人就盯的更仔細看了。其中發現了証書還多加了一個extension: X509v3 Subject Directory Attributes而且值很古怪。
例: https://crt.sh/?id=12589745529
值: 30 17 30 15 06 07 60 86 76 01 64 02 01 31 0a 06 08 60 86 76 01 64 03 03 01
這段ASN.1解出來的OID是長這個樣:
SEQUENCE {
SEQUENCE {
OBJECTIDENTIFIER 2.16.886.1.100.2.1
SET {
OBJECTIDENTIFIER 2.16.886.1.100.3.3.1
}
}
}
OID 2.16.886是什麼呢？看 http://oid-info.com/get/2.16.886 說是自1998年就中華電信就hijack/誤用了也門的OID範圍，大概他們以為電話是886那OID的範圍也是886，實際上台灣有另一個正式範圍2.16.158的。
誤用了這個範圍是一回事，大概是歷史原因。然後就被問到今天這個實際有什麼用呢？
而按照中華GTLSCA的Certification Practice Statement只是說用來進一步識別Subject (例如是政府？是公司？)
CPS: https://gtlsca.nat.gov.tw/download/GTLSCA_CPS_v1.0.3_eng.pdf (p.74-75)
找到的另一份文件有具體說那些值是什麼: http://grca.nat.gov.tw/download/GPKI_Cert_and_CRL_Profiles_v2.0.pdf
//小插曲: 也被管理員抓到英文翻譯錯導致有明顯邏輯衝突，但BR規定應該是英文版才是權威版本//
到這裡有2件事:
### 1. 廢止錯誤的証書大幅延遲的incident report: https://bugzilla.mozilla.org/show_bug.cgi?id=1903066
原先EKU問題另加OID問題要廢止的上萬張証書，理論上subscriber (使用者)在申請証書時就要接受証書隨時可能因任何原因，會被CA要求24小時或5日裡廢掉，但中華電信跟subscriber一一聯系後說他們都有各種理由沒有這種準備，而且很多要不說是關鍵基建、要不就是要請求上司……總之他們也不敢一下子就動刀。另外，subscriber與中華電訊的合同中也沒有註明要求會要配合CA緊急廢止這樣。（作為服務提供方乙方而且甲方都是政府就很被動、有權力階梯問題，加上實然上証書用好好的又沒有實質安全問題，這東亞文化我們都懂…但專業的專案不吃這套
的確CA欸應該標準很高才對）
Chrome team那邊在comment 13就提出重點: "The revocation timelines described in 4.9 of the TLS BRs must be considered as superseding to those desires of a customer." 你堂堂CA管顧客什麼鬼？是不是不想活了。
作為CA應該要向subscriber強調這真的會出現，不能拿自己是基建是政府作擋箭牌，下次萬一個萬一是CA key漏了出去而要緊急24小時廢止怎麼辦？而且本來証書就每年一續，顧客也不太可能不懂更換流程，推搪技術有難度不會的都是藉口。
comment 40: Chrome team發現中華自己的Certificate Policy (CP)就有寫明不能在核能設備、航空設備中使用，但那在中華在comment 14中說airport control tower中使用所以不能緊急廢止不就打臉了嗎？專案管理員amir接著說看來你們又要開一個incident report了…竟然有人公然違反CP你們不知道。comment 42中華解釋說subscriber自己講錯啦，是乘客資訊系統而已不是控制塔。
CP: https://eca.hinet.net/download/ePKI-CP-v2.1-Eng.pdf
但…被問那你怎麼一開始說是控制塔？不是有聯系過嗎？中華說第一次通知他們要廢止時他們的確這樣說，但第二次再問他們時就反口補充不是啦是資訊系統。
最新comment 53有其他人問那是subscriber為了爭取不廢止所以唬爛吧？那中華你們接下來要怎樣防止他們講大話呢？
### 2. OID這邊開了另一個Issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1899466
管理員amir明確追問過好多次Subject Directory Attributes是有什麼用都沒有得到答覆，但BR規定在互聯網上公眾沒有用到的就不能加，也提問這東西那audit沒發現嗎？
中華表示過往的audit的確也沒有被發現或問到，然後最新解決方案是補發的証書中默默地刪掉這個extension就是。
我看他們也的確不知道為什麼要加和有什麼系統依賴著要用…原意應該在歷史中埋沒了。