RIPE RPKI publisher validation failed after Krill startup

RIPE’s RPKI archive was fine. Its front desk forgot the publishers.

Why it matters

A routine Krill restart left delegated CAs outside the publication door for two hours and 43 minutes. The old records stayed put.

Theo March9 November 2026Reading Time 2 minLast update: 9 November 2026

On 3 November, RIPE NCC’s Krill publication service rejected new delegated-CA entities for 2h43 after starting before its publisher configuration was available; existing repository entities remained intact.

Summary

RIPE NCC’s RFC 8181 publication endpoint rejected delegated CA requests as ‘Unknown publisher’ from 20:07 to 22:50 UTC on 3 November 2026.
Krill started before slow storage supplied its publisher configuration. Existing repository content was unaffected; failed publications resumed after the configuration was restored.

The archive was open; the intake desk had forgotten who its customers were. During routine maintenance on 3 November, RIPE NCC restarted Krill, the service behind its RPKI Publication as a Service. Storage was slow to supply the publisher configuration. Krill came up first and answered every new publication request with the same verdict: “Unknown publisher.” The RFC 8181 endpoint could not validate the delegated certificate authorities that were already registered to use it.

RIPE’s incident clock runs from 20:07 to 22:50 UTC: two hours and 43 minutes. A member reported the failure. An engineer on the 24/7 team supplied the correct configuration, and unsuccessful publications resumed automatically. RIPE says the objects already in its RPKI repository were unaffected. That distinction is the story. A certificate authority could still have its signing keys and still fail to get a newly signed object into the repository that others fetch.

In RIPE’s delegated CA arrangement, members run their own certificate authority while using RIPE’s publication repository. The objects can include route-origin authorisations, manifests and revocation lists. The incident therefore sat at a narrow but consequential handoff: the signer knew what it wanted to publish; the repository’s front door did not recognise the signer.

RIPE’s proposed repair is specific. It will make publisher configuration available before Krill starts and seek monitoring for the RFC 8181 side of the service. The incident report gives no count of affected authorities or rejected object changes. A request log and validator evidence would put a number on the effect beyond the failed write path.

Sources: RIPE NCC incident report; RIPE NCC delegated CA guide.