Zusammenfassung

  • RIPE NCC meldet, dass sich BGPsec-Routerschlüsselzertifikate jetzt über die RPKI-API erstellen und verwalten lassen.
  • Das Zertifikat autorisiert einen an eine ASN gebundenen Schlüssel. Es bringt weder einen Router zum Signieren noch dessen Nachbarn zum Prüfen des Pfads.

BGPsec hatte ein Problem, das nach Schalter und Formular roch: Der Standard kannte das Routerschlüsselzertifikat längst, doch Betreiber mussten dessen Ausstellung erst in ihre normale RPKI-Arbeit einpassen. RIPE NCC hat dafür nun einen Weg über die API geschaffen. Antrag und Verwaltung des Zertifikats lassen sich per Software erledigen. Router erscheinen trotzdem nicht nach einem Mausklick im Rack.

Im Mitglieder-Update vom 23. Oktober kündigte RIPE NCC an, dass die RPKI-API BGPsec-Routerschlüsselzertifikate erstellen und verwalten kann. Einen Tag zuvor erläuterte Tim Bruijnzeels, Principal Engineer bei RIPE NCC, in der RIPE Routing WG, dass Inhaber einer ASN einen Routerschlüssel zum Signieren von BGP-Updates autorisieren können. Die öffentliche API-Dokumentation verweist für BGPsec auf die RPKI-Pilotumgebung localcert.ripe.net und beschreibt das Anlegen von Schlüsselobjekten sowie den Abruf von Zertifikat und Zertifikatskette. Damit ist eine Provisionierungsfunktion dokumentiert; weder die Zahl der produktiv nutzenden Mitglieder noch ein allgemein verfügbarer Produktionsendpunkt sind genannt.

Das Zertifikat hat einen präzisen Zweck. RFC 8209 definiert ein RPKI-End-Entity-Zertifikat, das einen öffentlichen Schlüssel an eine oder mehrere ASNs bindet. Der Router verwahrt den passenden privaten Schlüssel und nutzt ihn, sofern er BGPsec unterstützt, um Pfadinformationen beim Senden eines BGPsec-UPDATEs an einen externen Peer zu signieren. Der empfangende Router kann den signierten Pfad anhand der verfügbaren Zertifikate und Signaturen prüfen.

Das ist eine andere Aufgabe als bei den übrigen RPKI-Objekten. Eine ROA legt fest, welches AS ein Präfix originieren darf. Eine ASPA verzeichnet die Provider, die ein AS-Inhaber autorisiert. BGPsec trägt Signaturen entlang des AS-Pfads. Bruijnzeels nennt diese Funktionen ausdrücklich ergänzend. Das Routerschlüsselzertifikat ist ein Bauteil der Pfadsignatur, kein neuer Name für Origin-Validierung oder Leck-Erkennung.

Der aufschlussreichste Satz der Nachricht ist nicht die Ankündigung, sondern Bruijnzeels’ Hinweis, dass die Unterstützung in Hardware-Routern hinterherhinkt und inkrementelle Einführung sowie Leistung weiter Probleme bereiten. Eine API nimmt an einer Stelle Handarbeit heraus. Sie handelt keine BGPsec-Sitzung für den Router aus, schützt keinen privaten Schlüssel im Gerät, bringt dem Nachbarn nicht das Verständnis des signierten Attributs bei und entscheidet nicht, was bei einem fehlenden signierten Pfad geschehen soll.

Die Betriebskette ist übersichtlich: Zertifikat beantragen; privaten Schlüssel schützen und installieren; BGPsec auf kompatiblen Routern und Sitzungen aktivieren; signierte Updates senden; und sie von den empfangenden Routern validieren lassen. Für jede Stufe ist ein anderer Teil des Betriebs zuständig. Eine erfolgreiche API-Antwort belegt die erste. Öffentliche Unterlagen nennen weder einen allgemeinen Produktionszugang für alle Mitglieder noch Routerimplementierungen, die die übrigen Stufen abgeschlossen haben. RIPE NCCs eigener Ingenieur nennt die Hardwarelücke. Genau dort muss die nächste Meldung ansetzen.

Für Betreiber ist das ein echter Schritt. Die Zertifikatsausstellung gehört zur Control Plane und lässt sich per API zusammen mit anderen RPKI-Aufgaben automatisieren. Ein überzeugender Praxistest verbindet ein Zertifikat mit einem konkreten Router, einem geschützten Schlüssel, einem BGPsec-Peer und einem UPDATE, dessen Signaturen validiert wurden. Die API vereinfacht bisher einen Teil der Bereitstellung. Der Pfad unterschreibt sich noch nicht selbst.

Quellen: RIPE NCC Member Update, 23. Oktober 2026; Tim Bruijnzeels, RIPE Routing WG, 22. Oktober 2026; RIPE-NCC-Dokumentation zur BGPsec-API; RFC 8209; RFC 8205; RIPE-851, Certification Practice Statement.