1.7 Million Certificates Revoked in 24 Hours — Would Your Environment Survive?

Two mass revocation events in one week exposed a gap most teams don't know they have.

In the span of two weeks, the WebPKI ecosystem stress-tested mass certificate revocation twice — once by accident and once on purpose. Both events pointed at the same uncomfortable question: when your CA says "replace everything now," can your infrastructure actually respond?

What Happened

SSL.com — April 2, 2026: A security researcher reported that SSL.com's EJBCA-based ACME service had an incorrect implementation of Multi-Perspective Issuance Corroboration (MPIC) — the requirement under Baseline Requirements Section 3.2.2.9 that CAs validate domain ownership from multiple geographically distinct network locations to prevent BGP hijacking attacks. The flaw allowed domain control validation (DCV) to complete using only the remote network perspectives, bypassing the primary perspective check entirely. Approximately 1.7 million ACME DV certificates were affected. SSL.com executed their Mass Revocation Plan and revoked every one of them within 24 hours. Their full incident report is due April 17.

Let's Encrypt — March 19, 2026: Let's Encrypt ran their first annual mass revocation drill, required under Mozilla Root Store Policy v3.0, which took effect in 2025 and mandates that every CA in Mozilla's root program maintain and annually test a mass revocation plan. Most CAs satisfy this requirement with a tabletop exercise — essentially a meeting where the team walks through the plan on paper. Let's Encrypt didn't stop there. They selected roughly 3 million real production certificates and shortened their ACME Renewal Information (ARI) windows to signal an emergency. In staging, certificates were actually revoked. In production, no certificates were revoked, but any ACME client properly implementing ARI would see the shortened renewal window and renew immediately. They announced it on the Let's Encrypt community forum, but didn't contact subscribers directly. After all, if automation is working, it should just work.

One was a real compliance incident. The other was a planned drill. Both revealed the same gap.

This Isn't New — It's Accelerating

Mass revocation events have been happening for years. What's changed is the scale and frequency:

• 2020: Let's Encrypt revoked 3 million certificates over a CAA rechecking bug. No coordination mechanism existed — subscribers found out by email and scrambled to renew manually.
• July 2024: DigiCert discovered they'd been performing improper domain validation for five years. They gave customers 24 hours to replace 83,000 certificates. CISA issued an emergency alert. Some customers couldn't meet the deadline. Some sued.
• September 2024: Let's Encrypt discovered a compliance issue affecting 133,613 certificates. They used ARI to signal emergency renewals. Only about 5.6% of affected certificates renewed via ARI. The other 94% weren't listening.
• April 2026: SSL.com revoked 1.7 million certificates in 24 hours over the MPIC flaw described above.

The pattern is clear: CAs will always have compliance issues requiring mass revocation. The question isn't whether it happens — it's whether your renewal pipeline can respond automatically when it does.

ARI: The Protocol Most ACME Clients Aren't Using Yet

ACME Renewal Information (ARI), published as RFC 9773, is the protocol extension designed to solve exactly this problem. It adds a renewalInfo endpoint to the ACME server. Here's how it works in practice:

Your ACME client polls the renewalInfo endpoint for each managed certificate. The CA responds with a suggestedWindow — a start and end timestamp indicating when the certificate should be renewed. Under normal circumstances, this is a window near the end of the certificate's lifetime. Nothing dramatic.

When the CA needs to trigger an emergency renewal — a misissuance event, a compliance failure, anything requiring mass replacement — they shorten the suggestedWindow to a time that has already passed. That's the signal: renew this certificate right now.

The response also includes a Retry-After header telling the client how often to check back. Let's Encrypt currently returns 21,600 seconds — that's 6 hours. The RFC specifies that clients MUST re-poll after this interval. That word choice is deliberate.

When the client renews in response to an ARI signal, it's supposed to include a replaces field on the new certificate order, identifying which certificate it's replacing. This allows the CA to revoke the predecessor immediately and waive rate limits that would otherwise block bulk renewals.

The Problem: Popular Clients Have Gaps

Certbot (v4.1.0+): Added ARI support in June 2025. It checks the renewalInfo endpoint and will renew early if the suggested window has passed. However, Certbot only checks ARI when its scheduled cron job or systemd timer runs — which could be twice a day, daily, or even weekly depending on your configuration. It also does not send the replaces field on renewal orders, meaning the CA can't immediately revoke the predecessor or waive rate limits. Partial ARI compliance is better than none, but it's still partial.

acme.sh: No ARI support at all. Feature request #4944 has been open on GitHub since January 2024. During a mass revocation event, acme.sh users find out by email and run --renew --force manually. "Manually" doesn't scale when the deadline is 24 hours and you're managing dozens of certificates.

Caddy: Full ARI support including the replaces field. Caddy runs as a long-lived service, not a cron job, so it checks ARI on the schedule the CA requests.

Lego: ARI support added in v4.16.

Custom implementations: If you built your own ACME client, check whether it implements the full RFC 9773 flow — renewalInfo polling, suggestedWindow processing, Retry-After compliance, and the replaces field on orders.

The Math

If your Certbot cron runs every 12 hours and a mass revocation gives you a 24-hour window, you'll probably make it. If it runs weekly, you won't. If you use acme.sh, you're not going to find out until someone emails you — or until your site goes down.

Your Mass Revocation Readiness Checklist

Here's what to check in your environment today:

1. Know your ACME client's ARI status. Which client are you running? Which version? Does it support ARI, and if so, does it send the replaces field? If you're on an older version of Certbot (pre-4.1.0) or using acme.sh, ARI isn't protecting you.

2. Check your renewal frequency. Open your crontab or systemd timer configuration. How often does certbot renew actually run? The default Certbot systemd timer runs twice daily, which is reasonable. But if someone changed it, or if you're running renewals manually on a schedule, verify the interval. For a 24-hour revocation deadline, you want checks at least every 6–12 hours.

3. Audit your non-ACME certificates. ARI only applies to ACME-managed certificates. Enterprise CA customers (DigiCert, Sectigo, Entrust) don't get ARI signals — renewal is manual or through their Certificate Lifecycle Management (CLM) platform. If you have certificates from multiple CAs, do you have a single view of what needs replacing? This is where tools like Venafi, Keyfactor, or similar CLM platforms earn their keep.

4. Test your own response time. Pick a non-critical certificate. Force-renew it. Time the process from decision to deployed-in-production. If that number is measured in hours for a single certificate, multiply it by your total certificate count and ask whether you can meet a 24-hour deadline.

5. Subscribe to your CA's incident channels. You should be monitoring the Let's Encrypt community forum, Mozilla Bugzilla's CA compliance category, and your commercial CA's status page and security advisories. If your CA announces a mass revocation and you find out from Twitter, you're already behind.

Why This Gets Worse Before It Gets Better

Under SC-081v3, maximum certificate lifetimes are shrinking on a fixed schedule:

• March 15, 2026: 200-day maximum (199 actual issued days)
• March 15, 2027: 100-day maximum (99 actual issued days)
• March 15, 2029: 47-day maximum (46 actual issued days)

Let's Encrypt is moving even faster — 64-day certificates by February 2027 and 45-day certificates by February 2028.

Shorter lifetimes mean more frequent renewals, which means a revocation window becomes a larger percentage of your certificate's total lifetime. A 24-hour revocation deadline against a 47-day certificate is a fundamentally different challenge than against a 398-day certificate. The automation you build today for mass revocation readiness is the same automation you'll need when 47-day certificates are the norm.

The two events in March and April 2026 weren't anomalies. They were previews. The teams that come through the next one without an outage will be the ones who answered the question now: can my environment replace all its certificates in 24 hours?