Summary

  • The announced rpki-client rejection did not arrive as a single 18 August event: that day's upstream change prepared version 9.9, while the relevant branch still warned instead of rejecting.
  • The latest portable release remained 9.8 on 21 August, and an independent rpki-client console was still processing AFRINIC objects while exposing other repository errors, without displaying the old X.509 name warning.
  • The evidence supports a controlled compatibility transition, not a flag day or an outage. Operators must read notice, source, release and deployed validation as separate clocks before changing ROV policy.

One deadline became four operational clocks

The most consequential line in this story is not in a policy document. It is a disabled return statement in a validator.

On 19 February, rpki-client maintainer Job Snijders gave AFRINIC's Database Working Group an unambiguous date. Starting Tuesday, 18 August 2026, he wrote, the implementation would reject certificates whose X.509 issuer or subject commonName was not encoded as PrintableString. The warning tied that date to AFRINIC's own 31 July target for clearing the remaining objects. If the registry missed, the message said, affected members could face an RPKI service impact. The deadline is recorded in the public DBWG archive.

The date arrived. Upstream made a commit on 18 August titled Prepare for rpki-client 9.9 release, changing the version macro from 9.8 to 9.9. But the code that decides this particular issue did not make the threatened transition. In valid_printable_string(), a non-PrintableString name still causes a warning only at extra verbosity. The rejecting return 0 remains enclosed in #if 0, and therefore disabled, in the source at the 9.9 version commit.

Nor had 9.9 appeared as a published portable release by 21 August. The project's portable release page still identified 9.8, released in April, as the latest version. A source-tree version bump, a signed release and an operator's installed package are three different events. None should be substituted for another.

The date was therefore only the notice clock. The source clock had moved to a new version number but not to rejection; the release clock had not moved at all; and the deployment clock could only be inferred from independent validators and downstream packages.

An independent validator showed the fourth clock

The independently operated rpki-client console supplied the most useful deployed-state observation. Its 21 August run showed rpki-client -c -j actively fetching and validating the global repository set, including AFRINIC material. At 08:33 UTC it logged sequence gaps in two AFRINIC manifests and then two expired AFRINIC ROAs.

That log was not suppressing errors, yet it did not display the former non-PrintableString issuer- or subject-name warning. This is stronger than an issuer's self-report because the observation comes from a separate relying-party system. It is still an absence in one implementation's displayed log, not a cryptographic census of every AFRINIC certificate.

The bounded conclusion is therefore operational rather than celebratory. The deadline passed without the threatened reject branch appearing in the pinned source, while an independent validator continued to process AFRINIC material and surfaced different defects. That pattern is consistent with remediation having reduced the legacy exposure, but it does not establish when the final object was reissued or whether every relying-party implementation would agree.

A one-bit-looking defect with a long operational tail

The underlying fault was narrow. Its repair was not.

RFC 6487 section 4.5 constrains the subject and issuer names used in RPKI resource certificates. The commonName value is required to use the ASN.1 PrintableString type. AFRINIC's hosted system instead emitted UTF8String for these values after a 2022 upgrade.

In AFRINIC's March 2024 account, the registry traced the behavior to an updated OpenSSL configuration. The default was not behaving as the documentation had led implementers to expect. An OpenSSL documentation correction clarified that utf8only was the effective default mask and that nombstr was the relevant choice for PrintableString-compatible output.

Changing the signer fixed new issuance. It did not rewrite certificates and signed objects already in the repository. The affected hosted certification authorities had to be rekeyed, and dependent objects reissued. AFRINIC proposed doing that in batches to limit inconsistencies at publication points and reduce disruption for members with many end-entity certificates.

This distinction is central. A deterministic rule can be one line of code; changing the live objects to satisfy it is an operational migration. The registry controlled the signing system and the member coordination. Validator maintainers controlled the exception. Network operators controlled which versions they deployed. No single party could turn standards text into safe convergence by declaration alone.

The 6,000-route scenario was a warning, not an incident

The size of the remaining debt was measurable in late 2025. In a 17 November DBWG message, Snijders reported 988 objects with a nonconformant issuer name and 657 with a nonconformant subject name. If rpki-client had removed its exception at that point, he estimated that unique validated ROA payloads under the AFRINIC trust anchor would have fallen temporarily from 21,027 to 19,480.

The modeled routing effect was about 6,000 BGP announcements moving from ROV valid to not-found until the associated ROAs were reissued. That would not have made those routes automatically invalid, nor would it necessarily have made them unreachable. It would have withdrawn one form of cryptographic origin assurance from announcements that previously enjoyed it.

Those numbers describe a counterfactual in November 2025. They are not evidence that 6,000 announcements changed state in August 2026. No public incident report reviewed for this article establishes such an event. Conflating a stress estimate with an observed outage would turn a successful-looking migration into a fictional failure.

The more defensible reading is that the scenario concentrated attention on the right dependency. As long as the old objects remained, strict validation would transfer the cost of an issuer defect to resource holders and operators. Once the objects were reissued, the same validation rule could become ordinary standards enforcement rather than a regional service hazard.

The four clocks avoided a forced flag day

There were two possible orders of operation.

In the risky order, a relying-party implementation first withdraws its compatibility exception. Objects that the registry still serves then fail a stricter check, and operators temporarily lose VRPs while resource holders or the registry repair the chain. Standards purity arrives first; operational continuity pays the transition bill.

In the safer order, the issuer corrects the signing path, rekeys the affected hosted authorities, reissues dependent objects and verifies that the defect population has drained. Only then does the relying-party implementation remove the exception. The network sees convergence rather than a flag day.

The evidence available on 21 August points toward the second order, though it is not yet complete. The independent console was processing AFRINIC objects without surfacing the legacy name warning, while pinned rpki-client source still carried the tolerant branch. That is preferable to the inverse state, in which strict code encounters a repository full of known legacy objects.

It should not become a reason to keep the exception indefinitely. Registry-specific leniency is technical debt in software that operators expect to apply a common validation profile. Once multiple independent observations confirm that the affected population is gone, the exception can be removed with far less risk. The deadline's lasting value may therefore be that it synchronized attention across four clocks, not that it produced an 18 August cutover.

What the public evidence still cannot answer

AFRINIC has not, in the sources reviewed here, published a final technical report identifying the exact last reissuance time, the number of hosted authorities rekeyed in the closing phase or the validation matrix used for completion. A January discussion quoted plans for instructions, member communications and a helpdesk, while participants asked for a firm timetable. That exchange documents the coordination plan, not its complete execution record.

The public rpki-client console is also one observation point. It proves that an independent run was processing AFRINIC objects and reporting other errors; it does not prove that every object was conformant or that Routinator, Fort or every downstream build produced the same result. The expired ROAs and manifest sequence gaps in that run are separate findings, with no evidence tying them to the former UTF8String issue.

Finally, the state of upstream source is not the state of every installed validator. Downstream distributions can lag, patch or package different snapshots. Conversely, a future upstream commit can enable rejection before a portable release reaches operators. The correct statement is dated: at the 18 August 9.9 version bump, rejection was still disabled; on 21 August, 9.8 was still the latest published portable release.

The lesson is not that dates are useless. Deadlines expose who owns which part of a transition. But in routing security, completion has to be read from repository objects, validator source, release artifacts and the deployed fleet. Lu Heng's Running-Code Primacy supplies the right hierarchy: publication becomes operationally real through implementation, validation, deployment and adoption. On 21 August, those clocks described a managed compatibility gap, not the single switch promised in February.

Sources