Zusammenfassung

  • Ein unabhängiger rpki-client-Lauf verarbeitete am 21. August AFRINIC-Material, ohne die frühere X.509-Warnung für Aussteller- und Subjektnamen auszugeben; ein Lauf ist jedoch keine Vollerhebung aller Validatoren.
  • Der rpki-client-Commit vom 18. August bereitete lediglich die Versionsnummer 9.9 vor. Die eigentliche Ablehnung bleibt mit #if 0 deaktiviert, und die jüngste veröffentlichte portable Version war am 21. August weiterhin 9.8.
  • Die rund 6.000 BGP-Ankündigungen, die von ROV valid zu not-found wechseln könnten, waren eine bedingte Risikorechnung aus dem Jahr 2025 und kein nachgewiesener Vorfall im August.

Ein Termin, vier Zeitachsen

Am 19. Februar 2026 kündigte rpki-client-Maintainer Job Snijders in der Database Working Group von AFRINIC an, dass die Implementierung ab Dienstag, dem 18. August, Zertifikate ablehnen werde, deren X.509-Aussteller- oder Subjektname den commonName nicht als ASN.1-PrintableString kodiert. AFRINIC hatte sich zuvor den 31. Juli als Ziel für die Bereinigung der verbliebenen Objekte gesetzt. Ein Verfehlen, so die Warnung, könne für betroffene Mitglieder RPKI-Dienste beeinträchtigen. Die Nachricht dokumentiert Frist und Risiko, aber nicht die spätere Umsetzung.

Am 18. August erschien tatsächlich ein Upstream-Commit mit dem Titel Prepare for rpki-client 9.9 release. Er änderte die Versionsangabe von 9.8 auf 9.9. Die für diesen Fall entscheidende Prüfung blieb jedoch unverändert tolerant.

In valid_printable_string() erzeugt ein commonName, der nicht vom Typ PrintableString ist, weiterhin nur bei erhöhter Ausführlichkeit eine Warnung. Das return 0, das die Prüfung scheitern ließe, befindet sich nach wie vor in einem #if 0-Block und wird nicht kompiliert. Dies ist der Stand des Quelltexts beim 9.9-Versionscommit. Der Kommentar nennt die Warnung einen künftigen Fehler; der ausführbare Pfad tut es noch nicht.

Auch eine portable Version 9.9 war bis zum 21. August nicht veröffentlicht. Auf der Release-Seite des Projekts blieb die im April erschienene 9.8 die jüngste Ausgabe. Damit liefen vier Uhren auseinander: die Ankündigung, der Upstream-Quelltext, das portable Release und die tatsächliche Einführung bei Betreibern. Der Stichtag belegt deshalb keine flächendeckend aktive Ablehnung.

Auf der Ausstellerseite ist dagegen eine Veränderung sichtbar, die das eigentliche Risiko weitgehend entschärft.

Die Betriebsuhr wurde von außen beobachtet

Am 21. August um 08:33 UTC zeigte eine unabhängige öffentliche rpki-client-Konsole einen Lauf mit rpki-client -c -j. Er verarbeitete AFRINIC-Material, meldete Lücken in Manifest-Sequenzen und zwei abgelaufene AFRINIC-ROAs, enthielt aber nicht mehr die frühere Warnung, dass ein commonName nicht als PrintableString kodiert sei.

Die anderen Fehlermeldungen sind relevant: Die Ausgabe war kein leerer Erfolgsschirm, sondern machte gefundene Probleme sichtbar. Trotzdem lässt sich aus dem Fehlen einer Zeile in einem Lauf keine kryptografische Vollzählung ableiten. Ausführlichkeitsstufe, Programmversion und Abrufpfad können das Protokoll beeinflussen; andere Relying-Party-Implementierungen können anders reagieren.

Der Lauf ist deshalb ein unabhängiges Signal, das zu einer weit fortgeschrittenen Neu-Ausstellung passt, aber kein endgültiges Abnahmezeugnis. Für einen Zusammenhang zwischen den dort gemeldeten Manifest-Lücken oder abgelaufenen ROAs und dem früheren UTF8String-Fehler gibt es keinen Beleg.

Die zentrale Risikobedingung hat sich dennoch verändert. Der befürchtete Bruch setzte voraus, dass beim Beginn strenger Validierung viele Altobjekte vorhanden wären. Ein externer Lauf konnte AFRINIC-Material verarbeiten, ohne die Warnung auszugeben, die diesen Bestand bezeichnete.

Eine kleine Typabweichung verlangte eine große Migration

RFC 6487 Abschnitt 4.5 legt die Aussteller- und Subjektnamen von RPKI-Ressourcenzertifikaten fest. Der commonName muss als PrintableString kodiert sein. Nach einem Upgrade des RPKI-Systems im Jahr 2022 erzeugte AFRINICs gehostete Plattform diese Werte stattdessen als UTF8String.

In AFRINICs Erklärung vom März 2024 wurde das Verhalten auf eine aktualisierte OpenSSL-Konfiguration zurückgeführt. Die Dokumentation vermittelte ein falsches Bild vom tatsächlichen Standardwert. Eine Korrektur der OpenSSL-Dokumentation stellte klar, dass utf8only effektiv die Voreinstellung war und nombstr die Ausgabe auf PrintableString-kompatible Typen beschränkt.

Die Korrektur des Signierpfads löste das Problem für neue Ausgaben. Bereits signierte und veröffentlichte Objekte änderten sich dadurch nicht. Die betroffenen gehosteten Zertifizierungsstellen mussten neue Schlüssel erhalten und ihre abhängigen Objekte neu ausstellen. AFRINIC plante die Arbeiten in Chargen, um Inkonsistenzen an den Publikationspunkten zu vermeiden und Mitglieder mit vielen End-Entity-Zertifikaten besonders vorsichtig zu behandeln.

Hier trennt sich die eindeutige Regel von der betrieblichen Umsetzung. Eine Typprüfung passt in wenige Zeilen; die Migration verknüpft Schlüssel, Zertifikate, Manifeste, ROAs, Validator-Caches und Mitgliederkommunikation. AFRINIC kontrollierte die Ausstellung, die Validator-Maintainer die Ausnahme und Betreiber die Einführung neuer Versionen. Kein einzelner Termin konnte alle Ebenen gleichzeitig umstellen.

Die Zahl 6.000 war ein Belastungsszenario

Am 17. November 2025 meldete Snijders noch 988 Objekte mit nicht konformem Ausstellernamen und 657 mit nicht konformem Subjektnamen. Würde die Ausnahme damals entfernt, so seine Schätzung, fiele die Zahl eindeutiger VRPs unter dem AFRINIC Trust Anchor vorübergehend von 21.027 auf 19.480. Rund 6.000 BGP-Ankündigungen könnten von ROV valid auf not-found wechseln, bis die betreffenden ROAs neu ausgestellt wären. Die DBWG-Nachricht enthält Zahlen und Bedingung.

Diese Rechnung beschrieb keinen bereits eingetretenen Zustand. Not-found ist außerdem nicht gleichbedeutend mit invalid oder unerreichbar; einer Ankündigung fehlt dann die zuvor vorhandene validierte Ursprungsautorisierung.

In den ausgewerteten öffentlichen Quellen gibt es keinen Beleg dafür, dass im August 2026 tatsächlich 6.000 Ankündigungen ihren Status verloren. Die Schätzung als Vorfallszahl zu verwenden, wäre sachlich falsch. Sie bleibt ein Stresstest dafür, was eine zu frühe Entfernung der Ausnahme verursacht hätte.

Gleichzeitig zeigte sie, warum die Ausnahme kein Dauerzustand sein darf. Solange die alten Objekte existierten, hätten Ressourceninhaber die Folgen eines Ausstellungsfehlers getragen. Nach ihrer Bereinigung tragen Nutzer und Prüfer des Validators die Kosten eines unnötigen Sonderfalls. Die richtige Reihenfolge löst diesen scheinbaren Gegensatz zwischen Konformität und Kontinuität auf.

Vier Zeitachsen zeigen den verbliebenen Kompatibilitätsrest

Wird der Validator zuerst streng, verschwinden VRPs, während Mitglieder unter Zeitdruck nacharbeiten. Der Quelltext entspricht dem Profil, doch laufende Netze bezahlen die Umstellung.

Korrigiert der Aussteller zuerst die Signatur, erneuert die gehosteten CAs, stellt abhängige Objekte neu aus und weist den leeren Restbestand nach, wird die spätere Entfernung der Ausnahme zu einer risikoarmen Vereinheitlichung.

Die Signale vom 21. August entsprechen eher dem zweiten Ablauf. Der unabhängige Lauf zeigte die alte Warnung nicht, während rpki-client den toleranten Zweig noch besitzt und das portable Release 9.9 ausstand. Dieser Zustand ist dem umgekehrten vorzuziehen, in dem strenger Code auf ein Repository voller Altlasten trifft.

Eine dauerhafte AFRINIC-Sonderregel lässt sich daraus nicht ableiten. Spezieller Code vergrößert den Prüfaufwand und erschwert den Vergleich zwischen Validatoren. Sobald mehrere unabhängige Beobachtungen bestätigen, dass keine betroffenen Objekte mehr vorhanden sind, kann die Ausnahme mit deutlich geringerem Risiko entfallen.

Der Stichtag könnte deshalb als Koordinationsinstrument erfolgreich gewesen sein, obwohl die vier Zeitachsen nicht zusammenfielen. Das entspricht Heng Lus Argument für den Vorrang laufenden Codes vor bloßen Ankündigungen: Entscheidend sind der veröffentlichte Ausführungspfad und unabhängig beobachtbares Verhalten, nicht das Datum allein.

Welche Belege noch fehlen

Die öffentlichen Unterlagen nennen weder den exakten Zeitpunkt der letzten Neu-Ausstellung noch die Zahl der in der Schlussphase erneuerten gehosteten CAs. Im Januar wurden AFRINIC-Pläne für Anleitungen, Mitgliederkommunikation und einen Helpdesk zitiert; Teilnehmer bemängelten einen fehlenden Zeitplan. Dieser Austausch belegt die Absicht, nicht den Abschluss jeder Maßnahme.

Die unabhängige Konsole ist ein Beobachtungspunkt, keine implementierungsübergreifende Erhebung. Mehrere Validatoren mit dokumentierten Versionen, Optionen und Material-Fingerabdrücken würden die Aussage stärken. Auch der Softwarestand muss datiert bleiben: Beim Versionscommit vom 18. August war die Ablehnung deaktiviert; am 21. August war 9.8 das jüngste portable Release. Spätere Commits oder Downstream-Patches können das ändern.

Innerhalb dieser Grenzen ist die Nachricht dennoch belastbar: Ein Termin zerfiel in vier Zeitachsen. Die Ankündigung lief ab, der Quellbaum bewegte sich, das portable Paket blieb zurück und ein unabhängiger Lauf sah die alte Warnung nicht. Eine RPKI-Migration endet nicht mit einem Kalenderdatum, sondern mit der Übereinstimmung von korrekten Objekten, veröffentlichtem Code und tatsächlich eingesetzter Software.