Summary

  • RIPE NCC says its RPKI API now supports creating and managing BGPsec Router Key Certificates.
  • The certificate authorizes an ASN-linked router key. It does not make a router sign BGP updates or make a neighbour validate them.

For years, BGPsec had a familiar problem: the standard knew what a router key certificate should look like, while the operator still had to get that certificate into the machinery. RIPE NCC has now added a route through its RPKI API. The certificate can be requested and managed in software. The routers, rather inconveniently, still need to exist.

RIPE NCC’s 23 October member update says the API can create and manage BGPsec Router Key Certificates. A day earlier, Principal Engineer Tim Bruijnzeels told the RIPE Routing Working Group that an AS holder can authorize a key for a router to sign BGP updates. The public API documentation points users to RIPE NCC’s RPKI pilot environment at localcert.ripe.net; it describes creating router-key objects and retrieving certificates and chains. That is a concrete provisioning step, not a public count of members already using it in production.

The certificate has a precise job. RFC 8209 defines it as an RPKI end-entity certificate binding a public key to one or more ASNs. The operator keeps the matching private key; a BGPsec-capable router uses it to sign path information when sending a BGPsec UPDATE to an external peer. A receiving BGPsec speaker can then check the signed path against the certificates and signatures it has available.

That is a different job from the other familiar RPKI objects. A ROA says which AS may originate a prefix. ASPA records an AS holder’s provider authorizations. BGPsec carries signatures along the AS path. Bruijnzeels explicitly calls the three complementary. A router-key certificate is one piece of the path-signing machinery, not a new label for origin validation or leak detection.

The interesting sentence in the RIPE NCC engineer’s note is not the announcement. It is the admission that hardware-router support is lagging, with incremental deployment and performance still difficult. A certificate API removes paperwork from one point in the chain. It cannot negotiate a BGPsec session for a router, protect a private key inside a chassis, make a neighbour understand the signed attribute, or decide what a network does when the signed path is absent.

The rollout therefore has a visible ladder: request a certificate; protect and install the private key; enable BGPsec on suitable routers and sessions; send signed updates; and have receiving speakers validate them. Each rung belongs to a different operational owner. An API success response proves the first rung. The public sources do not yet name a general production endpoint for all members or identify router implementations that have completed the remaining steps. RIPE NCC’s own engineer says support in hardware routers is lagging. That is the next fact the rollout needs.

For an operator, this is still useful progress. Certificate issuance is a control-plane task, and an API makes it automatable alongside other RPKI work. The step becomes meaningful when it can be tied to a specific router, a protected key, a BGPsec-enabled peer and a validated update. Until then, the API has made one part of the path easier to provision. It has not made the path sign itself.

Sources: RIPE NCC Member Update, 23 October 2026; Tim Bruijnzeels, RIPE Routing WG, 22 October 2026; RIPE-NCC BGPSec API documentation; RFC 8209; RFC 8205; RIPE NCC Certification Practice Statement, RIPE-851.