CRLSet

How CRLSet Works

CRLSet is a browser-side revocation safeguard that keeps a local list of certificates the browser should refuse, even before the issuing authority’s own revocation data is fully available. It does not replace PKI validation, but it adds a fast, preloaded blocklist layer for specific high-risk certificates.

This matters because revocation is often a time-sensitive trust decision. If a certificate is compromised, misissued, or otherwise unsafe, the browser can stop trusting it without waiting for the normal revocation ecosystem to catch up.

Why Browsers Use a Local Revocation List

Standard certificate revocation checks can be delayed by distribution, caching, network reachability, or inconsistent CA publication. A local mechanism reduces that lag by embedding a curated set of known-bad certificates directly into the client trust decision.

That design is intentionally narrow. CRLSet is meant to catch a small number of especially important revocations, not to serve as a complete replacement for CRLs, OCSP, or broader certificate lifecycle controls. It is a defensive shortcut for urgent cases, not a universal revocation strategy. For a broader treatment of revocation models, see the Certificate Revocation Guide.

What CRLSet Does Not Do

CRLSet is not a general-purpose certificate inventory, and it does not guarantee that every revoked certificate will be blocked. It only helps when the browser vendor has included a specific certificate in the preloaded set.

That limitation means organisations should not treat browser-enforced revocation as the only control. Certificate hygiene still depends on CA governance, revocation publication, monitoring for misissuance, and rapid replacement of exposed certificates. In broader certificate incident response, a CA compromise and mass certificate replacement playbook is the right operational complement.

Operational and Security Implications

When a certificate is blocked through CRLSet, the effect is immediate trust refusal in the browser. That can prevent continued use of a compromised or misissued certificate, but it can also create availability impact if the block is broader than the organisation expected or if replacement certificates are not ready.

The security value is highest when revocation needs to happen faster than the normal CA ecosystem can propagate the change. The operational trade-off is that local revocation mechanisms are opaque to many certificate owners, so teams need inventory, monitoring, and fast reissuance capability to avoid service interruption.

Risk and Threat Considerations

CRLSet reduces exposure when a browser needs to reject a known-bad certificate quickly, but it is necessarily selective. If a compromised or misissued certificate is not yet present in the local blocklist, users can still connect until other revocation checks or trust updates take effect.

Failure mechanism: An attacker or misissue event can remain useful until the browser vendor distributes the specific certificate into the local revocation set, leaving a temporary window where normal PKI trust would otherwise still appear valid.

Impact: That gap can prolong impersonation risk, man-in-the-middle exposure, or continued use of a certificate that should no longer be trusted, especially where the affected service is public-facing or widely relied upon.

Practitioner Guidance

What to watch for: Treat CRLSet as a browser-enforced safety net, not a substitute for certificate inventory and revocation readiness. Organisations should know which public certificates they operate, which CAs issued them, and how quickly they can revoke and replace them when a compromise or misissuance event occurs.

Governance implication: Teams that own web services, PKI, or trust-store operations should align incident response with browser revocation behaviour, because client-side blocklists can change the effective recovery path even when the CA has not finished updating its own status data.