Why issue a certificate twice?
Cloudflare manages roughly 45 million TLS certificates, handling everything from issuance to deployment to renewal. Most renewals are routine, triggered by expiration dates. But some are not: key compromises, vulnerabilities, and CA-initiated mass revocations can force re-issuance of large numbers of certificates at short notice, and waiting until a problem occurs to start ordering new certificates from a CA is risky.
The mitigation Cloudflare is introducing is backup certificates. Every new Universal certificate order will also trigger an order for a second certificate, issued from a different CA and wrapped with a different private key. If the primary certificate is compromised or revoked, the backup is already available to deploy.
The events that trigger re-issuance
Renewal is normally a scheduled operation. When Cloudflare sees that a certificate is close to expiring, it initiates a renewal order so a new certificate is deployed before the old one expires. Two categories of events disrupt that schedule:
Key compromises
A key compromise means an unauthorized party has obtained the private key. This can happen via a vulnerability such as Heartbleed, or through malicious access by an insider. The response has to be immediate: generate new keys, deploy new certificates, and revoke the compromised ones.
Heartbleed in 2014 is the canonical example. Although no Cloudflare keys were actually leaked, the company re-issued certificates for all customers as a precaution. At that time the scale was around 100,000 certificates, which was manageable. At today's scale, the same kind of event could take weeks if it required new orders and validations at emergency speed.
CA mass revocations
The CA/Browser Forum Baseline Requirements oblige Certificate Authorities to revoke certificates whose keys are at risk within 24 hours, and certificates involved in policy violations within five days. CAs do occasionally invoke mass revocations: Let's Encrypt revoked roughly 2.7 million certificates in one incident, and another CA used by Cloudflare revoked certificates impacting about five thousand Cloudflare-managed domains.
In those cases Cloudflare was able to mitigate before the revocation took effect, relying on cooperation with the CA and quick engineering work. But that approach does not scale to a revocation affecting tens of millions of certificates. Issuing backup certificates from a different CA ahead of time means that even a mass revocation becomes a deployment problem, not an issuance problem.
Removing the bottlenecks to re-issuance
Re-issuing certificates at scale has two pain points: CA capacity and Domain Control Validation (DCV).
Cloudflare orders certificates from external CAs. In an emergency, those CAs would also be under load, and Cloudflare does not control their capacity. Pre-issuing backup certificates shifts the work to normal times.
DCV is the other issue. When Cloudflare is the authoritative DNS provider, it can add DCV records on the customer's behalf, making issuance and renewal automatic. For partial zones — domains that keep their DNS elsewhere but proxy traffic through Cloudflare — HTTP DCV can be completed from the edge, but only if the traffic is already being proxied. For a customer that wants a certificate before proxying, DCV requires manual steps. Relying on manual work during an emergency, with a short window and high stakes, is not acceptable.
For this reason, backup certificates are initially limited to domains using Cloudflare as authoritative DNS. For those domains, Cloudflare completes DCV for both the primary and the backup CA. Partial zones will be supported later; where Cloudflare cannot complete DCV, customers will receive the DCV records to finish issuance themselves.
Rollout plan
Backup certificates are being deployed on Universal Certificate orders for Free customers using Cloudflare as their authoritative DNS provider. The rollout is gradual: over the next few weeks, every new Universal certificate pack order on Free, Pro, and Biz accounts will include a backup certificate with a different key from a different CA.
Enterprise customers will see backup certificates starting at the end of April. Support for Advanced Certificates and SSL for SaaS certificates is planned, as is backup coverage for customer-uploaded certificates. The longer-term goal is to make backup certificate deployment instantaneous, so that in an emergency, swapping to a clean certificate is a deployment operation rather than an issuance scramble.
