Summary

  • On 3 November 2026, RIPE NCC’s RFC 8181 Publication as a Service endpoint rejected publication requests from 20:07 to 22:50 UTC. A restarted Krill process was ready before its publisher configuration was available.
  • Existing repository contents stayed intact and failed delegated CAs resumed publication after repair. The outage separated a readable repository from a broken write entrance, and a member report triggered the fix.

The service was up; its memory was late

A registered publisher should not have to introduce itself to the same service after maintenance. RIPE NCC’s incident account says that is effectively what happened on 3 November. The RFC 8181 endpoint used by its Publication as a Service stopped validating publishers at 20:07 UTC. Every publication request received “Unknown publisher.” The service was repaired at 22:50 UTC: two hours and 43 minutes during which delegated certificate authorities could not publish objects.

The mechanism was unusually plain. During regular maintenance, the system restarted. Krill, the service handling publication requests, came up before its configuration was available because storage was slow. Without the list of registered delegated-CA publishers, a running endpoint treated valid clients as strangers. RIPE NCC’s 24/7 engineer made the correct configuration available after a member reported the problem.

It is tempting to describe this as an RPKI outage and move on. That loses the most useful distinction. RIPE NCC says the content already in the RPKI repository was unaffected. Its delegated-CA guidance explains the split: an operator can hold its own CA keys and generate signed material, while RIPE NCC runs the repository that receives and serves that material. A CA publishes objects such as ROAs, manifests and certificate revocation lists through the publication arrangement. On 3 November the existing shelf remained in place; the counter accepting new files was closed to its recognised users.

That matters to an operator changing an authorisation or renewing material. A stable old repository can keep validators reading the objects already there. It cannot, by itself, make a rejected new object appear. RIPE NCC reports that affected delegated CAs resumed publication automatically after the service was repaired. The public incident report gives no count of CAs or attempted objects, so it cannot tell an individual operator whether a particular intended update was delayed; the CA’s own publication receipt and the repository object are the evidence for that case.

A green maintenance ticket is a different test

RIPE NCC’s status record for RPKI Dashboard maintenance was marked complete at 21:06 CET, or 20:06 UTC, on the same day. The publication failure began at 20:07 UTC in the separate incident record. These entries describe different service surfaces. The earlier Theo account examined the status page’s competing Dashboard labels. This event exposes an operational gap behind the labels: a process can restart and a maintenance ticket can close while a publish request still fails the only test that matters to a delegated CA.

RIPE NCC has named two corrective moves. It will make configuration available before Krill starts and look for better monitoring of the RFC 8181 part of the service. The first addresses the startup order. The second addresses detection: the registry’s account says a member’s report brought the problem to its engineer. An internal check that submits a valid publisher request after every restart would test the entry point, not merely whether the process answered.

The service terms give this boundary an institutional owner. A delegated CA retains its keys; RIPE NCC supplies the publication service and repository. The incident did not corrupt the old repository. It showed that a promise to host a dependable repository also needs a dependable route for its legitimate publishers to change what is hosted.