Summary

  • A routing-working-group reply reported that Ben Cartwright-Cox was the first to use RIPE NCC’s new API to publish a BGPsec router key certificate. The RIPE repository contains a certificate issued on 22 October for AS212232.
  • RFC 8634 lays out five stages: publish the replacement certificate, let RPKI caches fetch it, switch the router and refresh UPDATEs, optionally revoke the old certificate, then withdraw the old key when its validation expires.

The first certificate has left the desk

BGPsec moved from a feature announcement to a file an operator can inspect. On 22 October, RIPE NCC announced that its RPKI API could create and manage BGPsec Router Key Certificates. Hours later, a reply in the same routing-working-group thread congratulated Ben Cartwright-Cox for using the API to publish the first one. RIPE’s public repository carries a BGPsec Router certificate issued that day for AS212232. It is a modest object with an unusually consequential next step: somebody has to change the key on a live router without making the signed path disappear.

The certificate is specific. Its extended key usage is BGPsec Router, its key usage is digital signature, and its AS resource is 212232. It was issued at 14:43:46 UTC on 22 October and expires on 1 July 2027. A certificate is the public half of the arrangement: it lets relying systems associate an authorized ASN with a public key. The router holds the matching private key. RIPE NCC’s API accepts a PKCS#10 certificate signing request rather than asking the operator to upload that private key.

The public API documentation lists the lifecycle controls: create a router key, list keys associated with a certification authority, fetch one, revoke it, and retrieve its certificate or issuing chain. Access uses an API key created for each LIR with Resource Certification (RPKI) API permission. The request supplies an ASN, a BGP Identifier called routerId, and a CSR; the certification authority assigns the router-key ID. That is an automation surface with a clear custody line. The operator retains the signing secret; the CA issues and publishes the certificate.

That custody line makes the first certificate more interesting than a release note. BGPsec signatures follow the AS path in a BGP UPDATE. They answer a different question from a ROA or origin validation, which checks whether an AS may originate a prefix, and from ASPA, which records provider relationships and helps identify route leaks. The router certificate authorizes a key for BGPsec use. Routers and peers still have to sign and validate the path.

Rotation is where the calendar earns its keep

RFC 8634 gives key replacement five stages. Publish the new certificate; allow RPKI caches around the world to fetch it; switch the router to the new key and refresh outbound BGPsec UPDATEs; optionally revoke the old certificate when old-key messages must be invalidated; then, when the old certificate’s validation expires, relying parties signal key withdrawal through the RPKI-Router Protocol and routers remove old-key-signed routes. The staging period keeps peers from receiving signatures before they can find the matching public key.

An API can make its own calls easy; it cannot compress the propagation clock. A sensible change record would bind the replacement certificate to its publication time, cache visibility, router cutover, refreshed UPDATEs and any optional revocation. The final withdrawal follows the old certificate’s validation expiry. A script that jumps from “create” to “revoke” would be impressively efficient at manufacturing an outage.

RIPE NCC says hardware support for BGPsec is lagging and names incremental deployment and performance as challenges. RFC 8207 notes that some routers may need more memory or newer processors, and that partial deployments produce islands of signed paths. Those constraints matter to the key-change plan: the operator needs to know which edge routers sign, which peers validate, and where the signed chain stops.

The public API documentation still points to the RPKI pilot at localcert.ripe.net; the repository holds the AS212232 certificate issued on 22 October. RIPE’s public record still needs one dated rollover trace linking that certificate’s fingerprint and publication time to a router cutover, a refreshed signed UPDATE, and validation by named BGPsec peers; that trace would show how far the API has carried BGPsec into live routing.

Sources: RIPE routing working group announcement and first-use reply, 22 October 2026; RIPE raw router certificate; RIPE NCC BGPsec API documentation; IETF RFC 8209; IETF RFC 8205; IETF RFC 8207; IETF RFC 8634.