弯弯的政府 CA 瞎写证书模版被屌了，附时间线及演义

此处从 moz 的 bugzilla 采样讨论，经过英译中译中后量化为简单的模型供各位吃第一口瓜，
本文内容或有错漏与不足，有兴趣围观更多的请去原帖。

故事很长但很乐，建议往下看。想看神奇回复直接跳到 故事步入高潮 部分。

日期均以叙述时间为准，即帖子时间为 PDT ，台湾两个 CA 方口中的时间鬼知道哪个时区，可以默认 +8 。

故事的主角是 GTLSCA （下称 CA 方），或者说 政府伺服器數位憑證管理中心 CA ，
听名字就知道其特色所在了，下面展示其证书签发列表供各位感性认知一下：

此 CA 是 中华电信 Root CA （下称 根 CA ） 的下级。

故事的前摇

下面的内容主要为 1887096

2023 年 4 月 11 日，CA/B 普通的一天，
这一天他们正式发布了他们的 签发与管理公共证书的基线要求 2.0 (Baseline Requirements for the Issuance and Management of Publicly‐Trusted Certificates ，下简称 BR)。

2023 年 9 月 15 日，BR 2.0 正式生效。

2024 年 2 月 26 日，据 CA 方 所说，他们内部此时看 BR 的时候发现 extKeyUsage 扩展不得标记为 critical (可以理解为“如果不支持此扩展，则不得使用此证书”)，并提议做出修改。

2024 年 3 月 11 日，CA 方 称于此时间节点修复了此问题，我找了一张此时发布的证书，确实已经修复。

2024 年 3 月 19 日，chrome 去信给 中华电信 称发现三张来自 GTLSCA 的问题证书，
CA 方紧急开会吊了这 3 个证书，
然后和根一起 发了个帖子 表示我们第一时间解决问题，而且自查发现了 6450 张要吊销的， 所以我们是负责任的好 CA （大概

此时 CA 方 还没意识到问题的严重性，宣布 4.5 之前要吊销所有有问题的证书。

2024 年 3 月 22 日，CA 方 似乎是意识到了以本岛政府部门的资安水平，这么快吊销好像要出事，发了个信时间表表示我们到 4.17 吧。

2024 年 4 月 8 日，Rob Stradling 先生感到不太对劲：心想：你小子 BR 看到狗身上去了？这明明写着你得在 5 天内吊销所有的证书，你没按时 revoke 必须再写一份报告。
而且根据 CCADB 的规定，你事故报告得写受影响证书的清单。

2024 年 4 月 10 日，CA 方 po 出了他们的第一份清单，同时标题中表示，这些都是延迟吊销的证书。

2024 年 4 月 11 日，CA 方 完成了他们重签发 6450 张证书的伟大工作，
并将吊销延迟到了 5.15 。

2024 年 4 月 12 日，战神三哥 amir 在主贴中上线。

2024 年 4 月 21 日，amir 在问出了几个无关痛痒的程序问题后出了一记重拳：
捞翔，恁这证书里面怎么还有些我看不懂的玩意啊？
参考：此证书 Subject Directory Attributes 部分

CA 方：这是我们内部用的，2.16.886.1.100.2.1 (上面部分解码后的值) 表示这是政府部分，我们台湾国际区号是 886 ，这很合理吧
amir：但是 OID 数据库说这是你们 1998 年从人家也门那里抢过来的啊
amir：既然这些 OID 是错的，是不是这些也全该吊销啊？
Ryan Dickson：*贴出一堆 BR 内容以表示 CA 方 再次把 BR 看到狗身上去了*

2024 年 5 月 24 日，在讨论内容无法挽回后，CA 方 联系人表示 我们已经停发并消除此问题。
一般路过纯路人：你们得吊销重发才行
amir：确实，得再开个事故报告

2024 年 5 月 28 日，CA 方：行吧，我们吊

故事真正开始

下面内容涉及 1899466

当 5 月 28 日 CA 方 开贴的那个中午，或许他们的内心已经在颤抖，
他们发出了一份涉及 12991 张证书的事故报告，每一张都需要他们吊销并通知对应部门替换。

幸运的是，因为两个月前 chrome 的突然袭击，他们现在学会了一部分流程， 开篇给出了一个还算完整的答卷，有时间线，有预计时间节点，还有证书列表。

但是 mozilla 的人们并没有让他们好过太久，
CA 方 上一次吊销大延迟并且没能按要求给出事故报告，
（ CRL 显示，CA 方 直到 4.24-25 才吊销了大部分证书，我会在下面给出 CRL 附件）
而这一次 CA 似乎又忘了 BR 中 5 天的底线，给出了整整 49 天的吊销计划，
这令社区其他人士十分恼火，开始狂轰滥炸：

5 月 29 日
Wayne：中华电信看过自己的证书政策吗？
CA 方（并非 CHT ）：政府的设备有 SLA ，我们需要时间换

6 月 14 日
CA 方：吊销了 4306 了，我们在和政府部门谈
amir：你谈你🐎，你是想当公共认可的 CA 还是政府狗腿子？

6 月 14 日
Wayne：你们咕个没完，CHT 还有很多要做的（指名威胁） 根 CA （ CHT ）：你说得对，我们马上去找他们开会

故事步入高潮

下面内容涉及 1903066

GTLSCA 部分发现了社区想要什么，此时给出了一个完整的时间表表示我们要延迟多久。

但社区不会满足于此，更何况，这可是 CA/B 社区的一部分。

6 月 18 日
Mike Shaver 和 Tim Callan 各自发布了一段长长的讨罪檄文釜底抽薪直取根 CA ，奠定了新帖的质疑基调。
他们一个老生常谈，要求 CHT 给出一个符合政策的报告，
另一个则直接质疑 CHT 在主贴中并不承认吊销是因为他们的错误，也没有给出任何相关的说明。

6 月 20 日
CA 方使用了超级套话回复，反正要是我，我已经气笑了：

我们随后制定了一些补救措施，以避免再次发生类似事件。
1.与用户达成的条款强调，我们必须遵守 BR 时限，并履行 CA 的责任。不能接受的政府机构不应使用 GTLSCA 颁发的 TLS 证书。（：？）
2.同步系统更新程序，将 CHT 的 BR 程序和证书配置文件同步给 GTLSCA ，并在 deadline 前完成更新，以确保格式符合 BR 。（早干嘛去了）
3.加强教育和培训指导，使用户能够真正理解 CA 为遵守 BR 而需要遵守的规则，以及这些规则需要用户的充分合作。（政府：你在教我做事啊）

感谢你的建议，我们知道错了，并且要承担责任。

6 月 20 日
Wayne：你们是不是搞错了什么，你得给一个证书和对应延迟吊销理由的详细列表啊（比划） GTLSCA：好嘞我懂，并给出一张统计表：

6 月 24 日
Zacharias：我没有看到 CHT 避免这种事情再次发生做的事情，
而且 mozilla 愿意接受特殊情况下不延迟吊销可能出问题，但你一个都没解释 CA 方：*精华原文见图*
其中举例：空管要爆炸（划重点，要考）

7 月 11 日
Chrome 来人乱入：我看了你们的规章制度，里面怎么写着：不能用于航空设施啊？

7 月 13 日
CA 方：说错了，他们一开始告诉我这玩意跟 ATC 有关，
我们又去问了问，其实就是给旅客看日程表的

7 月 14 日
walter.j.marks：所以说你们一开始是知道他跟 ATC 有关，还是不知道他跟 ATC 有关？
CA 方：是用户在被打电话通知吊销的时候说的，不关我事

附 CRL 地址： http://gtlsca.nat.gov.tw/crl/GTLSCA-complete.crl

可以用 OpenSSL 转成可读格式 openssl crl -inform DER -in GTLSCA-complete.crl -text