摘要

  • rpki-client承诺的拒绝没有在8月18日作为单一事件到来：当天提交准备了9.9版本号，相关分支却仍然只警告、不拒绝。
  • 8月21日portable最新正式版仍是9.8；与此同时，一个独立rpki-client控制台正在处理AFRINIC对象，会暴露其他仓库错误，却没有显示过去的X.509名称警告。
  • 证据指向一次受控的兼容迁移，而不是“旗标日”或中断。运营者在调整ROV策略前，必须把通知、源码、发布包和部署分别读成四只时钟。

一个截止日变成了四只运营时钟

基础设施里的日期很容易被误读成事实。邮件可以宣布切换日，仓库可以写入新版本号，但真正决定结果的是条件分支是否改变、发布包是否产生，以及运营者是否部署。

2026年2月19日，rpki-client维护者Job Snijders在AFRINIC Database Working Group邮件列表中给出了明确警告：从8月18日星期二起，rpki-client将拒绝X.509签发者或主体commonName没有使用ASN.1 PrintableString编码的证书。AFRINIC此前把7月31日定为清理剩余对象的目标；如果错过，邮件称受影响成员可能遇到RPKI服务问题。这封公开邮件构成了截止日的来源，但它不是后来已经执行切换的证据。

8月18日，上游代码库确实出现了一个与日期高度吻合的动作：Prepare for rpki-client 9.9 release。提交把版本宏从9.8改成9.9，却没有启用这项拒绝逻辑。

在负责检查名称类型的valid_printable_string()中，非PrintableString的commonName仍只会在额外详细模式下产生警告。让验证直接失败的return 0依旧放在#if 0块内，不会被编译执行。9.9版本号提交对应的源码把这件事写得很清楚：注释说“应当成为错误”，代码却仍然是宽容模式。

截至8月21日，portable发布页列出的最新正式版还是4月15日发布的9.8。准备版本、签发正式包、进入操作系统软件源、最终部署到验证器，是四个不同的状态。仅凭“9.9”出现在源码里，不能宣布硬切换已经发生。

独立验证器显示了第四只时钟

独立运行的rpki-client控制台给出了最有用的部署侧观测。8月21日那一轮显示，rpki-client -c -j正在抓取和验证全球仓库集，其中包括AFRINIC材料。08:33 UTC起，日志先报告了两个AFRINIC manifest的序号跳跃，随后又报告了两个已过期的AFRINIC ROA。

这份日志没有隐藏错误，却没有显示过去针对非PrintableString签发者名称或主体名称的警告。它比签发方自己的陈述更独立，但仍只是一个实现的公开日志中没有某类消息，并不是对每一张AFRINIC证书的密码学普查。

因此，最稳妥的是给出运营结论，而非庆功结论：截止日过去时，固定版本源码里仍没有拒绝分支；独立验证器继续处理AFRINIC材料，并暴露其他缺陷。这与历史对象暴露已经收缩相一致，却不能确定最后一次重签的时间，也不能替所有依赖方实现作保证。

控制台中的过期ROA和manifest序号跳跃是另外的问题。没有证据把它们与过去的UTF8String错误联系起来，不能为了制造戏剧性而混为一谈。

一个类型错误，为什么拖成三年迁移

RFC 6487第4.5节规定了RPKI资源证书中的主体和签发者名称格式，其中commonName必须采用PrintableString。AFRINIC在2022年升级RPKI系统后，托管平台却用UTF8String生成了这些值。

AFRINIC在2024年3月的说明中把根因指向升级后的OpenSSL配置。文档让实现者误判了默认行为；后来提交的OpenSSL文档修正说明，有效默认值是utf8only，若要把输出限制在与PrintableString兼容的类型，应使用nombstr。

修正签名路径只能保证新签发正确，无法改写已经签名并发布的证书与对象。剩余工作需要对受影响的托管CA重新生成密钥，再重新签发依赖对象。AFRINIC当时计划分批维护，避免在发布点形成不一致，并为拥有较多终端实体证书的成员留出更谨慎的处理方式。

这正是“规范很薄，迁移很厚”的场景。验证规则可以是一行确定性判断；让活跃仓库满足规则，却涉及密钥、CA、manifest、ROA、缓存和成员协调。AFRINIC掌握签发与托管CA，验证器维护者掌握例外分支，下游发行版和网络运营者掌握部署速度。没有任何一方可以只靠发出命令，就让其余层面同时完成。

约6,000条通告是压力测试，不是事故数字

到2025年11月，问题规模仍然不小。Snijders在11月17日的DBWG邮件中报告：带有不合规签发者名称的对象为988个，带有不合规主体名称的对象为657个。如果当时立即删除兼容例外，AFRINIC信任锚下的唯一VRP数量预计会暂时从21,027降至19,480。

同一估算认为，大约6,000条BGP通告会从ROV valid变成not-found，直到相关ROA重新签发。Not-found不等于invalid，也不等于路由必然不可达；它表示对应通告暂时失去了原先的密码学来源授权证据。

更重要的是，这是一项带条件的反事实估算：如果在2025年11月就撤掉例外，会发生什么。它不是2026年8月的观测结果。本次研究没有找到公开事故报告，证明约6,000条通告在截止日真的改变了状态。把风险模型写成事故复盘，既不准确，也会掩盖看起来更值得肯定的结果——修复可能已经在硬拒绝之前完成。

这个估算真正发挥的作用，是把两种成本同时量化：长期保留单一注册局例外，会增加验证器债务；过早删除例外，则会把签发系统留下的问题转嫁给资源持有人和运营网络。只有先把对象修复，再统一验证行为，两个成本才不会被错误地二选一。

正确的收口顺序是先修公共层，再关兼容分支

如果验证器先变严格，仍在仓库中的旧对象会失败，VRP可能暂时消失，成员需要在压力下补救。规范一致性先到，运营连续性承担过渡成本。

如果签发方先修正软件、重置受影响托管CA、重新签发对象，并证明问题对象持续清零，那么验证器随后撤掉例外就只是完成收口，而不是制造“旗标日”。

8月21日的证据更接近第二种顺序。独立控制台处理AFRINIC对象时没有显示旧名称警告；固定版本的rpki-client源码尚未启用拒绝。这个状态优于相反状态——严格代码撞上满仓旧对象——但它不应成为无限期保留例外的理由。

针对特定注册局的宽容分支会让共同验证规则变得难以审计，也让不同实现之间更难比较。一旦多个独立观察点都确认对象群已经清空，删除例外的风险就会显著降低。2月截止日最终的价值，可能不是在8月18日准时拨动一个软件开关，而是迫使签发侧在开关真正拨动前完成清债。

还缺一份可复用的完成证明

公开材料没有说明最后一个受影响对象具体在何时重新签发，也没有给出最终阶段重置了多少个托管CA。1月的一次讨论引用了AFRINIC的计划：发布操作说明、通过常用渠道联系成员和社区、开设helpdesk；参与者同时指出计划缺少明确时间表。这段邮件记录证明协调方案曾被提出，却不能替代最终执行报告。

公开rpki-client控制台也只是一个观察点。它证明一次独立运行正在处理AFRINIC对象并报告其他错误，却不能证明所有对象都合规，也不能证明Routinator、Fort或每一个下游软件包得到相同结果。软件侧同样需要持续标注时间：8月18日版本号提交中的拒绝仍被禁用，8月21日portable最新发布仍是9.8。

在这些边界内，结论已经足够清晰：日期不是完成证明。Lu Heng的运行代码优先原则给出了正确层级——改变要通过实现、验证、部署与采用才成为运行现实。8月21日的四只时钟显示的是受管理的兼容间隙，而不是2月承诺的单一开关。