Revoking a Root CA Certificate

TL;DR

Revoking a Root CA certificate is extremely difficult and generally not possible in practice without significant disruption. It’s far better to prevent issuing bad certificates in the first place through robust processes and controls. If revocation *is* necessary, it requires coordinated action across all systems trusting that root.

Understanding Root CA Revocation

A Root Certificate Authority (Root CA) is at the top of a trust hierarchy. Everything else – intermediate CAs, end-entity certificates – relies on trust in the Root. Because of this central role, revoking a Root CA has massive implications.

Why it’s so hard

• Widespread Trust: Root CAs are pre-installed in most operating systems, browsers, and applications.
• No Direct Revocation Mechanism: Unlike end-entity certificates which use Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol (OCSP), there’s no standard revocation mechanism for Roots themselves.
• Coordination Nightmare: You’d need to update trust stores on *every* device and system that trusts the Root CA. This is practically impossible to achieve completely.

Steps if Revocation is Absolutely Necessary

1. Identify Affected Systems: Determine all systems, applications, browsers, and devices that trust the compromised Root CA. This is a huge undertaking.
2. Stop Issuing Certificates: Immediately halt any further certificate issuance from the compromised Root CA.
3. Publish a Certificate Revocation Notice (CRN): While not a formal revocation list, publish a clear and public notice detailing the compromise and advising users to distrust the root. This is often done through industry forums and security mailing lists.
4. Intermediate CA Impact: If you used intermediate CAs signed by the compromised Root, revoke *those* immediately using standard CRL/OCSP mechanisms. This limits the damage.

   openssl ca -revoke /path/to/intermediate.crt

   (Example command – adjust paths accordingly).

5. Distribute New Trust Anchors: The most effective, but also most difficult step. You need to distribute a new Root CA certificate or trust anchor to all affected systems. This often involves:
   • Software Updates: Vendors must release updates for their software (operating systems, browsers, etc.) with the updated trust store.
   • Manual Updates: For systems where automatic updates aren’t possible, manual intervention is required – a very time-consuming and error-prone process.
6. Monitor for Continued Trust: Continuously monitor systems to ensure the old Root CA is no longer trusted.

Alternatives to Full Revocation

• Shortened Certificate Validity Periods: If possible, reduce the validity period of certificates issued by the compromised root before it was compromised. This limits the window of opportunity for attackers.
• Key Rollover: Replace the Root CA with a new one and migrate systems to trust the new root. This is complex but avoids the full revocation issues.

Preventing Revocation – Best Practices

• Strong Key Protection: Protect the private key of your Root CA with Hardware Security Modules (HSMs) and strict access controls.
• Robust Processes: Implement thorough vetting procedures for certificate requests.
• Regular Audits: Conduct regular security audits of your CA infrastructure.
• Certificate Transparency: Use Certificate Transparency logs to detect mis-issued certificates.

Resources

• Let’s Encrypt Revocation Guide
• DigiCert CA Revocation Information