A revocation certificate is a small signed statement that marks a key as no longer valid. Create it at the same time as the key and store it separately. If the key is ever lost or stolen, you import the certificate and publish the revoked key.
What the GnuPG manual says
According to the GnuPG manual, the standard generate key command creates the key pair and also creates a revocation certificate, stored in the openpgp-revocs.d directory below the GnuPG home directory. A separate generate revocation command can create one for a complete key. The manual notes that this merely creates the certificate so it can be used if ever needed. To actually revoke the key, the certificate has to be merged into the key by importing it, and the revoked key then needs to be distributed.
To revoke only a subkey or a key signature, the manual points to the edit command instead.
Why create it early
The usual reason you need a revocation certificate is that something went wrong with the key: a lost laptop, a forgotten passphrase, a suspected theft. In the forgotten passphrase case you cannot create the certificate afterwards, because creating it requires the key. If you made it earlier and kept it, you can still revoke.
Steps
- Generate the key and note where the revocation certificate was written.
- Copy the certificate somewhere separate from the private key, such as an encrypted offline store held by a second trusted maintainer.
- Record in your runbook who can use it and how.
- Test the procedure on a throwaway key so the real one is not your first attempt.
If the day comes
- Import the revocation certificate into your keyring.
- Publish the revoked public key wherever the original is published.
- Announce it in release notes and on your verification page, with the new key's fingerprint.
- Review which releases were signed since the suspected exposure and decide whether any need re-issuing.
- Rotate any related credentials, such as CI secrets that held the key.
What revocation does not do
Revocation only works if users learn about it. A user who never refreshes the key will not see it. That is why a clearly dated notice on your own site matters, and why your verification instructions should tell users to refresh keys before verifying.
| Event | Needs revocation | Notes |
|---|---|---|
| Private key stolen | Yes | Act immediately |
| Passphrase forgotten | Yes | Only possible if you kept the certificate |
| Planned expiry | No | Extend or replace, see expired signing keys |
| Maintainer leaves | Often | If they held the private key |
Subkeys and scope
GnuPG keys often have a primary key and subkeys used for signing. The manual notes that revoking only a subkey or a key signature is done through the edit command. If only a signing subkey is exposed, a narrower revocation can be enough, and the primary key stays in use. If the primary key is exposed, revoke the whole thing. Decide the scope based on what the attacker could reach, and write that decision in your runbook before you need it.
Quick check
Where should I store the revocation certificate?
Away from the private key and protected, since anyone holding it can revoke your key. An encrypted offline copy with a trusted second person is common.
Is revoking the same as deleting the key?
No. Revoking publishes a notice that the key is invalid. Deleting only removes your local copy.
Sources
Last reviewed: 19 October 2026.
