When a Certificate Authority Loses Public Trust

Open an HTTPS website and the browser quietly checks the server’s certificate, hostname, dates, signatures, and chain of trust. Most of the time, this takes a fraction of a second and nobody thinks about it.

At the top of the chain is a certificate authority, or CA. These organizations are expected to be the careful adults of the internet: audited, documented, well protected, and trusted with keys that can affect millions of people.

That trust is enormous. Unless technically restricted, a public CA can issue a certificate for almost any domain. If it wrongly issues one for google.com, the connection can still be encrypted perfectly - but to the wrong server.

Certificate authorities therefore look like a model of reliability. Yet CAs have been hacked, delegated too much power, broken validation rules, hidden important changes, and lost the trust of browsers and operating systems. The following cases show how the public trust system behind TLS, usually called Web PKI, can fail.

How public certificate trust works

A website normally presents its own certificate and one or more intermediate certificates. The browser follows their signatures until it reaches a root certificate that it already trusts. The list of trusted roots is called a root store.

Mozilla, Google, Apple, Microsoft, and other root program operators decide which CAs their products accept. CAs must follow security, validation, audit, disclosure, and incident-response rules. The CA/Browser Forum publishes shared baseline requirements, and each root program can add its own rules.

Trust is not permanent. A vendor can remove a root, limit it, or reject certificates issued after a certain date. This last option gives existing customers time to move while stopping the CA from issuing new certificates that will work in that product.

Browsers are only the visible part

Browsers get most of the attention because their certificate errors are easy to see. But the same trust system is used across servers and applications.

A Linux server normally has a CA bundle used by TLS libraries and command-line tools. Both curl and wget verify certificates by default. If they cannot build a chain to a trusted CA, they refuse to connect.

The result can be much larger than a broken website. Package managers may stop downloading repositories. Container builds can fail to fetch images or dependencies. APIs, webhooks, backups, monitoring agents, payment integrations, control panels, and shell scripts may all return certificate verify failed.

Mail can also be affected. Strict TLS checks may prevent SMTP servers from delivering messages and leave mail in queues. SMTP submission, IMAP, POP3, and S/MIME for signed or encrypted email have their own certificate checks. Not every mail route will fail because policies differ, which can make the problem even harder to recognize.

Applications do not always use the same root store. A browser, operating system, Java runtime, curl build, and old container image may all have different trust data. One server works while an apparently identical server fails. Disabling verification with curl -k or wget --no-check-certificate is not a fix; it restores access by removing the identity check that TLS is meant to provide. The proper response is to replace the affected certificate chain and update the relevant trust stores.

DigiNotar: when attackers took over a CA

The 2011 DigiNotar incident remains the clearest example of a fully compromised CA. Attackers entered the Dutch company’s network and created certificates for Google, Yahoo, Mozilla, Microsoft, Skype, and other services. Mozilla first reported more than 200 fraudulent certificates; a later investigation identified 531, while poor logging made the exact total impossible to prove.

A fake *.google.com certificate was then used in a man-in-the-middle attack in Iran. DigiNotar’s logs showed requests from roughly 300,000 unique Iranian IP addresses. This was only an estimate of scale, not an exact user count, but the attack was clearly real and widespread.

The investigation found weak passwords, outdated software, poor network separation, missing logs, and CA systems joined to one Windows domain. DigiNotar had also known about fraudulent issuance for weeks before the public was told.

Mozilla completely removed DigiNotar from its root program, and other vendors followed. DigiNotar filed for bankruptcy in September 2011. A failure inside one Dutch company had put users in another country at risk, even though those users had never chosen DigiNotar themselves.

Comodo: when the weak point was a partner

Earlier in 2011, an attacker compromised the account of a registration authority partner working with Comodo. Such partners check identities or domains and can request certificates from the CA. The account was used to issue nine fraudulent certificates for Google, Microsoft, Yahoo, Skype, and Mozilla domains.

Comodo’s root key was not stolen, but the certificates were valid from a browser’s point of view. The case showed that a large CA could be only as safe as a partner network it did not operate.

Comodo detected the issuance quickly, revoked the certificates, suspended the account, and notified browser vendors. There was no evidence that the certificates had been used in an attack. Mozilla still criticized Comodo for issuing directly from a root instead of giving each partner a separate intermediate that could be revoked on its own.

Comodo kept browser trust. This contrast matters: the response depends not only on the original failure, but also on how quickly the CA detects, reports, contains, and fixes it.

CNNIC and MCS Holdings: when a firewall could impersonate websites

In 2015, CNNIC issued an unconstrained intermediate CA certificate to the Egyptian company MCS Holdings. This was not a normal website certificate. It could be used to issue trusted certificates for almost any domain.

MCS installed the certificate and private key in a firewall that inspected TLS traffic. The firewall could create a replacement certificate for each website, decrypt the connection, inspect it, and encrypt it again.

Companies often inspect TLS on managed devices, but they normally use a private CA trusted only by those devices. The MCS firewall chained to CNNIC’s public root, so ordinary browsers could accept its replacement certificates without a private corporate root being installed.

The available evidence suggested that the inspection stayed inside the customer’s network, and CNNIC revoked the intermediate. Mozilla first blocked that intermediate and then stopped trusting new certificates from CNNIC roots. One certificate had turned a corporate inspection device into a CA trusted far beyond the company.

WoSign and StartCom: when rules and honest reporting failed

Technical mistakes can be fixed. Misleading the organizations that supervise a CA is a deeper problem.

Mozilla found that WoSign had continued issuing SHA-1 TLS certificates after the January 1, 2016 deadline. It set earlier notBefore dates so the certificates looked older. Mozilla also found that WoSign had bought StartCom, the company behind StartSSL, without properly reporting the change of control. According to Mozilla, representatives denied both findings until enough evidence had been collected.

Mozilla then distrusted new certificates from WoSign and StartCom. Their roots were later removed from Firefox, and other vendors took similar action.

The main issue was no longer only SHA-1. Root programs depend on honest incident reports and accurate information about who controls a CA. Once those answers cannot be trusted, another audit is unlikely to solve the real problem.

Symantec: when control failed at enormous scale

Symantec was one of the largest certificate businesses and operated GeoTrust, RapidSSL, Thawte, and VeriSign. Its case was not one catastrophic hack, but a long series of control and validation problems.

In 2015, certificates were issued for Google domains without Google’s approval. Symantec said that employees involved in part of the activity had been dismissed. Later investigation found broader problems with validation and outside organizations that could cause certificates to be issued.

In 2017, Chrome said the scope had grown from 127 to at least 30,000 certificates issued over several years. This did not mean that all 30,000 were fraudulent. The problem was that browsers could no longer have enough confidence in the process behind them. Symantec disputed how the number was presented.

Removing trust at once would have broken many legitimate websites. Chrome and Mozilla therefore phased it out while site owners replaced their certificates. Symantec sold the CA business to DigiCert, but the sale did not restore trust in the old infrastructure. Mozilla completed its removal of trust for the affected TLS roots in Firefox 63.

TrustCor: when the concern was who stood behind the CA

The 2022 TrustCor case was different because no evidence of certificate misissuance was found.

Researchers were investigating Measurement Systems, whose SDK in Android applications was described as invasive spyware. They found corporate and technical links between Measurement Systems, TrustCor, and MsgSafe, an encrypted email service run by TrustCor. These included shared corporate officers and a version of the SDK inside a beta MsgSafe application.

TrustCor disputed allegations and said its businesses were separate. Mozilla still decided that the ownership and operational links created too much risk for a global trust anchor. It stopped accepting new TrustCor certificates after November 30, 2022 and planned to remove the roots after existing TLS certificates expired. Google also lost confidence in TrustCor, and Chrome 111 stopped trusting its roots.

The question was not “Did TrustCor issue a bad certificate?” It was “Do we have enough confidence in the organization that could issue one?” A CA’s ownership, management, transparency, and security culture are part of the trust decision too.

Entrust: the modern reminder

These problems did not end with old versions of Firefox. In 2024, Google announced that Chrome would stop trusting new TLS certificates under several Entrust and AffirmTrust roots. It cited six years of compliance failures, broken improvement promises, and too little measurable progress.

Chrome 131 began rejecting affected certificates logged after November 11, 2024. Mozilla made a similar decision with a November 30 deadline. Older certificates were allowed to continue for a time so customers could move.

The Chrome and Mozilla decisions show that a CA does not need to suffer a spectacular hack before trust is removed. Repeated failures and weak fixes can be enough.

Why Web PKI is stronger now

These stories can make the HTTPS padlock look less reassuring. But the system has also improved because of them.

Certificate Transparency creates public logs of TLS certificate issuance. Domain owners and researchers can watch for unexpected certificates. CT does not stop every bad certificate, but it makes hidden issuance much harder.

Root program oversight is more public. Mozilla policy, for example, requires audits, disclosure of CA hierarchies, incident reports, account protection, and compliance with CA/Browser Forum rules. Public discussions and bug reports are part of the security process.

Intermediate CAs receive more scrutiny. They must be disclosed and protected, and they must be audited unless they are technically limited. Modern browsers can also reject new certificates after a deadline while allowing older ones to be replaced. Shorter certificate lifetimes and automated renewal make that migration easier.

None of this is perfect. CT makes issuance visible but does not prevent it. Audits cannot watch every system continuously. Revocation has practical limits. Web PKI is still a managed trust system, not proof that every CA will behave correctly forever.

What operators should take from this

Infrastructure operators should assume that certificates and CAs can change. Automate issuance and renewal. Monitor Certificate Transparency for unexpected certificates. Use CAA DNS records if you want to list which CAs may issue for your domain. Document certificates on load balancers, mail gateways, appliances, and forgotten internal services.

Keep browsers, operating systems, runtimes, and TLS libraries updated. Distrust only protects a system after new trust data reaches it. Also remember that a valid domain-validated certificate mainly proves control of a domain at the time of issuance. It does not prove that the website is honest, safe, or run by people who answer support email.

Trust includes the ability to withdraw trust

Certificate authorities are almost invisible because the system usually works. Browsers open websites, servers download packages, applications call APIs, and mail systems deliver messages without users checking public keys by hand. That convenience gives a small group of organizations exceptional power.

DigiNotar showed what happens when a CA is hacked. Comodo exposed risk in partner networks. CNNIC showed the danger of a powerful intermediate certificate. WoSign and StartCom showed why honest reporting matters. Symantec demonstrated weak control at scale. TrustCor brought ownership and security culture into the decision. Entrust proved that these questions remain current.

The reassuring lesson is not that CAs never fail. They do. It is that certificates are now more visible, incidents are investigated in public, and trust can be removed when a CA no longer meets the standard. In Web PKI, the ability to stop trusting is part of trust itself.