Why Relying on a Single CA Is a Risk: Entrust, DigiCert, DigiNotar and the Case for Multiple Certificate Authorities

The entire security of public TLS rests on one simple premise: when your browser trusts a Certificate Authority (CA), it trusts everything that CA issues. It's a model of transitive trust — and that's exactly why it's fragile. The weakest link isn't your server or your private key. It's the CA itself.

Most teams pick a CA, wire up the issuance flow, and never think about it again — until the day that CA fails. And CAs fail in three distinct ways, all with real precedent and consequences that have taken sites offline and put companies out of business.

Managing public certificates is harder than it looks

Before the cases, it's worth understanding why this is operationally complex. A public certificate isn't just a file you install and forget. It carries:

• Domain control validation (DCV) that must be performed and, increasingly, re-performed on every renewal — via DNS, HTTP, or email.
• A chain of trust that depends on roots browsers can remove at any moment, without asking your opinion.
• A shrinking lifecycle — with the CA/Browser Forum's SC-081 ballot, maximum validity drops to 47 days by 2029, multiplying renewal events per certificate.
• Dependence on a third party — the CA — whose compliance health you don't control and rarely monitor.

It's that last point most teams underestimate. The three cases below show why.

Case 1 — Entrust: when a CA loses browser trust

This is the most recent case and the most instructive, because it involved no hacker at all. On June 27, 2024, Google announced that Chrome would stop trusting new TLS certificates from Entrust and AffirmTrust, following a series of compliance failures, unfulfilled improvement commitments, and insufficient progress on publicly disclosed incident reports over six years.

In practice: Entrust certificates with a Signed Certificate Timestamp (SCT) dated after November 11, 2024, stopped being trusted in Chrome. Mozilla followed with its own distrust starting December 1, 2024, and Apple set its own cutoff dates as well. Servers using those certificates began showing the "Your connection is not private" warning to users.

Entrust was not a small or obscure CA. Its importance came not from the volume of certificates it issued, but from who its subscribers were: governments, airlines, banks, and major corporations — organizations with revenues in the billions. These companies were forced to migrate CAs in a hurry to avoid service disruption.

The critical point: the distrust decision was outside the control of any Entrust customer. You could have done everything right — protected key, valid certificate, correct deployment — and still watch your site break, because the decision belonged to a third party (Google) about another third party (Entrust).

Case 2 — DigiCert: when a CA is forced into a mass revocation

In July 2024, DigiCert — one of the largest and most respected CAs in the world — had to revoke certificates over a flaw in its own domain validation process. The incident affected 83,267 certificates across 6,807 customers, roughly 0.4% of applicable domain validations.

The cause was technical and specific: in one of the validation methods, the customer sets up a DNS CNAME record with a random value provided by DigiCert, which then performs a lookup to confirm the values match. Due to changes introduced to the system starting in 2019, DigiCert stopped adding the underscore prefix to the random value used in CNAME-based validation — a flaw that went unnoticed for years.

The most serious part was the deadline. Ecosystem rules mandated revocation within 24 hours, and DigiCert made clear that all affected certificates would be revoked by August 3, 2024, 19:30 UTC, without exception. Some customers even filed legal action to try to block the revocation, and CISA (the U.S. cybersecurity agency) issued an alert about possible disruptions to websites, services, and applications.

Note the asymmetry: an internal UX change at DigiCert, five years earlier, resulted in thousands of organizations having 24 hours to swap certificates or go offline. None of those customers had visibility into or control over the flaw.

Case 3 — DigiNotar: when a CA is genuinely compromised

The canonical case of a hacked CA happened in 2011, and it changed the internet forever. Hackers breached the Dutch CA DigiNotar and issued more than 531 fraudulent certificates, including one for *.google.com.

The fake Google certificate was no academic curiosity. It was used to intercept the Gmail communications of an estimated 300,000 people in Iran — a state-scale man-in-the-middle attack against dissidents, activists, and journalists.

The root cause was mundane: the breach started through an outdated DotNetNuke installation — a known vulnerability with an available patch — and DigiNotar's public web server sat on the same Windows domain as its CA servers, so one compromised server meant all of them were compromised. The company had HSMs, but HSMs protect against physical theft, not against seemingly authorized access.

The outcome was terminal. Unlike Comodo, which survived its breach, DigiNotar was completely destroyed: browsers revoked trust in all its certificates, the Dutch government took over control, and the company declared bankruptcy within weeks. From breach to bankruptcy was 42 days. That episode was one of the drivers behind the creation of Certificate Transparency — the same mechanism that today lets you monitor unauthorized issuance.

The common pattern: you don't control the weakest link

Three cases, three completely different causes — a compliance failure, an operational validation error, and a criminal breach. One factor in common: in none of them did the CA's customer control what went wrong, yet all of them bore the consequences.

That's why AppViewX research found that 90% of Fortune 1000 companies use more than 3 Certificate Authorities — not by accident, but as a resilience strategy. Relying on a single CA concentrates in one third party a risk that can take your entire operation offline overnight.

Why multiple CAs change the game

Working with more than one CA turns a catastrophic event into a manageable one:

• If a CA loses browser trust (Entrust), you reissue affected certificates through the alternate CA, with no emergency migration.
• If a CA has to revoke en masse (DigiCert), critical certificates issued by another CA stay valid while you reissue the affected ones.
• If a CA is compromised (DigiNotar), you don't have 100% of your trust surface concentrated on the point that failed.

The question stops being "which is the best CA?" and becomes "how do I operate across several CAs without tripling the manual work?"

What this demands from your CLM

Supporting multiple CAs is only viable in practice if the certificate lifecycle management (CLM) platform absorbs the complexity instead of pushing it onto the team. When choosing a CLM, check whether it:

Supports multiple CAs natively. Issuance via Let's Encrypt, DigiCert, AD CS, and others from the same interface, without separate, disconnected integrations for each.

Automates domain validation (DCV). With SC-081 requiring revalidation on every renewal, manual DCV doesn't scale. The CLM needs to create, verify, and clean up validation records automatically — whether DNS-01, HTTP-01, or CNAME.

Lets you switch CAs without switching processes. Migrating a certificate from one CA to another should be a configuration change, not a project. If each CA demands a distinct operational flow, you don't have real redundancy.

Monitors the entire surface, not just what you issued. Continuous discovery and Certificate Transparency log monitoring to detect certificates issued for your domains — including unauthorized issuance, the direct lesson of DigiNotar.

Automates deployment, not just issuance. Reissuing through an alternate CA is pointless if the new certificate isn't automatically redistributed to every endpoint that consumes it.

CA resilience isn't a premium feature for large enterprises. It's the difference between a CA incident being a ten-minute configuration change or a 24-hour race against the clock — exactly what thousands of DigiCert customers lived through in August 2024.