Everything you never wanted to know about the Pwnedkeys Revokinator.

How does the Pwnedkeys Revokinator Work?

The Revokinator starts by scraping all known WebPKI certificates from Certificate Transparency logs and creating an index of the key they use. When new private keys are found to be compromised, they are checked against the index of certificates, and if any certificates are found using that key, the issuer(s) of those certificates are notified that the key is compromised.

This automatic process only catches cases where the key is found to be compromised after the certificate has been issued. The Revokinator does not currently have the capacity to check every certificate as it is scraped against the entire dataset of known-compromised keys (sponsorships welcome!). To find certificates which were issued to previously-compromised keys, a manual job is run now and then, which checks all existing keys against all indexed certificates. works by matching the Pwnedkeys dataset of compromised private keys against all known WebPKI certificates, and notifying Certificate Authorities of the compromised keys.

Every certificate which is found to use a compromised key is recorded as a "revocation candidate". A revocation candidate whose key has not previously been reported as compromised to the certificate's issuer produces a "revocation request". This request is sent to the issuer, providing details of the certificate involved and a cryptographic attestation that the key is compromised. Every attempt to deliver a revocation request is recorded, to detect problems with a CA's problem reporting infrastructure.

Once a revocation request has been successfully delivered, all certificates related to that request are checked against the OCSP server which handles that certificate. These OCSP checks are repeated periodically, and the details about each are recorded. From this, it is possible to determine how long it took the CA to revoke each certificate, and hence whether the CA is in compliance with the relevant requirements for WebPKI CAs.

How are compromised keys reported?

By default, problem reports are sent to CAs via email to problem reporting addresses listed in the CA's CPS (Certification Practice Statement). A single problem report per compromised key is sent, when that key has been identified as being associated with one or more certificates issued by that CA.

Problem reports can also be sent as an HTTP POST of a compromise attestation document, if a URL is specified in a CA's CPS, and that it accepts any compromise attestation format available via the Pwnedkeys API. Contact revokinator@pwnedkeys.com to notify us that your CPS has been amended appropriately.

The Revokinator site doesn't show me something I want to see!

Technically, that's not a question, but I'll allow it.

The source code for the Revokinator's public information site is publicly available. Pull requests implementing bug fixes and new features will be considered on a case-by-case basis, bearing in mind that the Revokinator does not have a huge amount of spare capacity, so changes that require significant resources to execute may not be suitable.

Can I get direct access to the Revokinator database to do my own research?

Direct access to the production Revokinator database is unlikely to happen, simply because running arbitrary queries on the database is likely to end badly, given the resource constraints that Pwnedkeys operates under. However, if you are a security researcher who would like access to the Revokinator data for your own purposes, it may be possible for you to get a replication slot to feed your own replica. Please email us to discuss how that might be arranged.

Can I track my own revocation requests with the Revokinator?

At present, there is no ability to track revocation requests not related to a compromised key known to Pwnedkeys. However, there is no fundamental reason why this couldn't be done, it's just that it hasn't been implemented. If you are a security researcher and would like to use the Revokinator system to track your revocation requests, including OCSP response history, please email us to discuss how we can work together.

Why doesn't the Revokinator use ACME to report compromised keys?

The ACME (Automated Certificate Management Environment) protocol provides a way for compromised keys to be reported, however it requires the private key itself to be available at the moment the notification is sent. Pwnedkeys (including the Revokinator) does not store private key material online, because a centralised database of millions of private keys would be like catnip for attackers. Remember that these keys are for live, real-world certificates, some for significant domains. The Pwnedkeys dataset includes keys for certificates such as *.gov.<ccTLD>, which I think we can all agree is not one we'd like every attacker on the planet to have trivial access to.

Instead, when a private key is ingested by the Pwnedkeys system, a "compromise attestation" is generated using the compromised key, and then the key itself is encrypted and stored offline, in a deliberately not-trivial-to-access manner. This compromise attestation is a document, signed by the key itself, which asserts that the key is compromised. The signature allows anyone who has the public portion of the key to verify that Pwnedkeys does, indeed, have access to the associated private key. This approach is a standard, secure, reliable way of demonstrating control of a private key.