楼主:
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就是。
我看他们也的确不知道为什么要加和有什么系统依赖着要用…原意应该在历史中埋没了。