To prepare a PGP key revocation certificate, generate it immediately after creating your key using gpg --gen-revoke, then store it securely offline, and publish it to a keyserver if your key is compromised. A revocation certificate is a specially formatted file that invalidates your PGP key permanently, allowing you to protect yourself even if your private key is lost or stolen. This guide walks you through generating, securing, and publishing your revocation certificate to ensure you can always regain control of your key’s trust status.

Why You Need a Revocation Certificate Now

Every PGP key pair should have a revocation certificate generated at creation time, not after a crisis. If you lose access to your private key before generating a revocation certificate, you cannot invalidate your key. Anyone who finds or steals that key can continue impersonating you indefinitely.

The revocation certificate is a specially formatted message that, when published to a keyserver, tells all software that the key is permanently invalid. It works even if you no longer have access to the original private key, as long as you have the revocation certificate.

Consider this scenario: your laptop is stolen with your PGP private key. Without a pre-generated revocation certificate, you cannot notify the world that your key is compromised. Anyone using an old copy of your public key will still encrypt messages to what they believe is your key, but whoever has your stolen key can decrypt them. The revocation certificate prevents this.

Generating Your Revocation Certificate

The GnuPG tool makes generating a revocation certificate straightforward. You need your key ID to begin.

First, list your keys to find the one you want to revoke:

gpg --list-secret-keys

This displays your secret keys with their key IDs. The output looks like this:

sec rsa4096/3AA5C6F7 2026-01-15 [SC]
      4A7C8E9F2B3D1A6C5E4F7890ABCDEF01
uid [ultimate] Your Name <your@email.com>
ssb rsa4096/7B8C9D0E 2026-01-15 [E]

The key ID is 3AA5C6F7 in this example. Replace it with your actual key ID in the commands below.

Generate the revocation certificate:

gpg --output revocation-certificate.asc --gen-revoke 3AA5C6F7

GnuPG prompts you to select a reason for revocation: key has been compromised, key is no longer used, or key is superseded. Choose the appropriate reason. For most users, “key has been compromised” is the correct choice.

The certificate saves to revocation-certificate.asc. This file contains the cryptographic proof that you, as the key holder, are revoking the key.

Securing Your Revocation Certificate

Where you store the revocation certificate matters as much as generating it. If an attacker gains access to your revocation certificate, they can publish it and invalidate your key without your consent. Store it with the same protection you give your private key.

Create a secure backup:

gpg --armor --export-secret-keys 3AA5C6F7 > master-key-backup.asc
tar -czf pgp-backup.tar.gz revocation-certificate.asc master-key-backup.asc
gpg -o pgp-backup-encrypted.tar.gz --symmetric --cipher-algo AES256 pgp-backup.tar.gz

Store the encrypted backup in multiple locations: a secure USB drive kept offline, a safe deposit box, or distributed with Shamir Secret Sharing if you want multi-party control.

Some users store the revocation certificate with their paper key backup, etched into metal or written in a secure location. The goal is ensuring you can access it even if your primary computer is destroyed or inaccessible.

Publishing the Revocation Certificate

When you need to use the revocation certificate, the process involves publishing it to key servers so the world knows your key is invalid.

Import the revocation certificate into your keyring:

gpg --import revocation-certificate.asc

Send the revoked key to a keyserver:

gpg --send-keys 3AA5C6F7

This uploads your now-revoked key to the default keyserver. Other key servers synchronize, propagating the revocation information. Within hours, most PGP software consulting these servers will show your key as revoked.

For more aggressive notification, send your revocation certificate directly to multiple key servers:

gpg --keyserver keyserver.ubuntu.com --send-keys 3AA5C6F7
gpg --keyserver pgp.mit.edu --send-keys 3AA5C6F7
gpg --keyserver keys.openpgp.org --send-keys 3AA5C6F7

Handling Key Revocation for Multiple Keys

If you manage multiple keys or have subkeys, each key requires its own revocation certificate. Master keys and subkeys are revoked separately.

List all your keys to see the structure:

gpg --list-secret-keys --keyid-format LONG

Generate revocation certificates for each key you want to be able to revoke independently:

gpg --output revoke-master.asc --gen-revoke MASTER_KEY_ID
gpg --output revoke-sub1.asc --gen-revoke SUBKEY_1_ID
gpg --output revoke-sub2.asc --gen-revoke SUBKEY_2_ID

Label each certificate file clearly to avoid confusion during an emergency.

Automating Revocation Certificate Generation

For users who frequently create new keys, automating revocation certificate generation prevents the common mistake of creating keys without certificates.

Create a simple wrapper script:

#!/bin/bash
KEY_ID="$1"
if [ -z "$KEY_ID" ]; then
    echo "Usage: $0 <key-id>"
    exit 1
fi
gpg --output "revoke-${KEY_ID}.asc" --gen-revoke "$KEY_ID"
echo "Revocation certificate saved to revoke-${KEY_ID}.asc"
chmod 600 "revoke-${KEY_ID}.asc"

Make it executable and use it:

chmod +x make-revoke.sh
./make-revoke.sh 3AA5C6F7

Alternative Revocation Methods

Beyond the traditional revocation certificate, modern PGP implementations offer alternative methods.

Designated revokers allow you to assign another key the authority to revoke your key. This helps in scenarios where you lose your key but have designated a trusted party:

gpg --edit-key YOUR_KEY_ID
addrevoker Trusted_Party_KEY_ID
save

Key expiration serves as a softer form of revocation. Setting your key to expire automatically makes it inactive after a certain date, though it can be extended if you recover access:

gpg --edit-key YOUR_KEY_ID
expire
save

Neither method replaces the revocation certificate, which remains the authoritative way to permanently invalidate a key.

Revocation Certificate Storage Best Practices

Physical Storage Options

Metal Storage (Most Secure)

# Print the revocation certificate on paper
gpg --export-secret-key 3AA5C6F7 | qrencode -o revocation-qrcode.png

# Options:
# 1. Etch QR code onto metal plate (fireproof, permanent)
# 2. Photograph certificate and store in safe deposit box
# 3. Use metal card engraved with key fingerprint and certificate hash

USB Drive Storage

# Create encrypted backup on USB
gpg --symmetric --cipher-algo AES256 revocation-certificate.asc
cp revocation-certificate.asc.gpg /media/usb-backup/

# Physical security:
# - Store in safe or lockbox
# - Use hardware-write-lock USB to prevent modification
# - Keep in separate location from main computer

Distributed Storage

# Use Shamir Secret Sharing to split certificate into parts
# Any 2 of 3 parts can reconstruct the certificate
# Distribute to trusted contacts

# Install ssss-split
sudo apt install ssss

# Split certificate into 3 parts (need 2 to reconstruct)
cat revocation-certificate.asc | ssss-split -t 2 -n 3

# Each part is useless alone, but any 2 reconstruct the certificate

Secure Storage Documentation

Create a document describing where you’ve stored your revocation certificate:

# PGP Key Recovery Instructions (CONFIDENTIAL)

Key ID: 3AA5C6F7
Fingerprint: 4A7C8E9F2B3D1A6C5E4F7890ABCDEF01

Revocation Certificate Locations:
1. Primary: Safe deposit box at [Bank Name], Box [Number]
2. Backup: Metal storage at [Location]
3. Emergency: USB encrypted backup with [Trusted Contact Name]

Access Instructions:
- Safe deposit box requires [ID Type] and signature
- USB drive password: [Stored separately in sealed envelope]
- If primary is lost, contact trusted contact for emergency backup

Review Schedule:
- Annual: Verify all copies are intact and accessible
- Upon address change: Update safe deposit box location

Store this document with your will or estate documents.

Testing Your Revocation Setup

Periodically verify that your revocation certificate is valid and would work if needed. This is a dry run—you import the certificate, check that your key shows as revoked, then restore the original state.

Create a test key for this purpose, or use a secondary key that you can afford to revoke temporarily. The verification process ensures you have the correct certificate and know how to use it.

Common Mistakes to Avoid

The most common mistake is generating the revocation certificate after a key is compromised. By then, it is too late. Generate the certificate immediately upon key creation.

Another error is storing the revocation certificate on the same device as the key itself. If that device is stolen or destroyed, you lose both. Use offline, separate storage.

Forgetting the passphrase for your backup is equally problematic. Document your backup procedures in a way you can recover but others cannot access.

Advanced Revocation Scenarios

Revoking Expired Keys

If a key has expired (either naturally or by setting an expiration), you may want to revoke it:

# Check key expiration
gpg --list-keys 3AA5C6F7

# Revoke an expired key
gpg --gen-revoke 3AA5C6F7

# Publish revocation
gpg --send-keys 3AA5C6F7

An expired key marked as revoked prevents future use more authoritatively than simply expiring.

Revoking Subkeys Without Revoking Master Key

If a subkey is compromised but your master key is safe:

# Revoke only the subkey
gpg --edit-key 3AA5C6F7
# At prompt: key <subkey-number>
# At prompt: revkey
# At prompt: save

# This invalidates only that subkey, not the entire key

This approach is better than revoking the whole key—you can create a new subkey and continue using the master key.

Emergency Key Revocation

If your key is actively compromised and you need immediate revocation:

# Generate revocation certificate immediately if you haven't yet
gpg --gen-revoke 3AA5C6F7 -a > emergency-revoke.asc

# Import it
gpg --import emergency-revoke.asc

# Send to multiple keyservers simultaneously
for server in keyserver.ubuntu.com pgp.mit.edu keys.openpgp.org; do
  gpg --keyserver "$server" --send-keys 3AA5C6F7 &
done
wait

# Announce via other channels (email, social media, website)
# "My PGP key [3AA5C6F7] has been revoked due to compromise"

Key Rotation After Revocation

When you revoke a key, you need to create a new one:

# Generate new key with transition statement
gpg --full-generate-key

# Create signed statement linking old key to new key
gpg --armor --output transition.asc \
  --sign <<EOF
This is a signed message stating that:

Old key: 3AA5C6F7 (REVOKED)
Fingerprint: 4A7C8E9F2B3D1A6C5E4F7890ABCDEF01

New key: 7X8Y9Z0A
Fingerprint: [New key fingerprint]

The old key was revoked due to [reason].
All future communications should use the new key.

Signed by the old key holder.
EOF

# Send transition statement to your contacts via multiple channels

Verifying Revocation Worked

After publishing a revocation certificate:

# Wait 1 hour for keyserver propagation
sleep 3600

# Check that your key shows as revoked
gpg --keyserver keyserver.ubuntu.com --recv-keys 3AA5C6F7
gpg --list-keys 3AA5C6F7

# The output should show [revoked: YYYY-MM-DD]

If the revocation doesn’t appear after 24 hours, try:

# Refresh keyserver
gpg --refresh-keys 3AA5C6F7

# Send to alternate keyservers
gpg --keyserver pgp.mit.edu --send-keys 3AA5C6F7
gpg --keyserver keys.openpgp.org --send-keys 3AA5C6F7

Revocation Certificate for Team Keys

For organizational signing keys shared among team members:

# Generate revocation with organizational designation
gpg --gen-revoke ORG_KEY_ID

# Designate multiple revokers so any authorized person can revoke
gpg --edit-key ORG_KEY_ID
# prompt: addrevoker [team-member-key-id]
# Repeat for multiple members
# prompt: save

# Distribute revocation certificate to all team members
# Store securely in team credentials manager

When the team member leaves:

# Any other team member can revoke using their authority
gpg --gen-revoke ORG_KEY_ID

Documentation Checklist for Revocation

Keep this with your key backup:

# Revocation Certificate Information

## Key Details
- Key ID: 3AA5C6F7
- Fingerprint: 4A7C8E9F2B3D1A6C5E4F7890ABCDEF01
- Created: [Date]
- Type: [RSA-4096 / Ed25519]

## Revocation Storage
- Location 1: [Specific location and access method]
- Location 2: [Specific location and access method]
- Emergency contact: [Name and contact method]

## Usage Instructions
1. Recover revocation certificate from storage location
2. Import: `gpg --import revocation-certificate.asc`
3. Publish: `gpg --send-keys 3AA5C6F7`
4. Notify contacts via [email/website/social media]
5. Generate new key if creating ongoing communications

## Keyserver Details
Primary keyservers:
- keyserver.ubuntu.com
- pgp.mit.edu
- keys.openpgp.org

## Transition Plan
New key location: [Where new key is stored]
Transition statement: [Link to signed transition statement]

A PGP key revocation certificate is not optional. It is a fundamental part of key management that protects you and your correspondents when things go wrong. Generate it, secure it, and know how to use it.

Related Articles

• How To Prepare Ssh Key And Server Access Documentation For T
• How To Manage Pgp Keys Securely Using Hardware Security Key
• How to Document DNS and SSL Certificate Renewal Procedures
• Vpn Authentication Methods Compared Certificate Vs.
• Vpn Certificate Pinning How It Prevents Mitm Attacks.

Built by theluckystrike — More at zovo.one