What is a certificate authority (CA)?

A certificate authority (CA) is the organization that issues digital certificates and, by signing them, vouches that a cryptographic key belongs to a given domain, company or person. It works like a notary: when a browser opens a site over HTTPS, it has never met that server, but it recognizes the CA's signature on the server's certificate and trusts that instead. At the top of the chain sits the root CA, whose key, under industry rules, does not sign certificates for websites; below it sit intermediate CAs, which the root authorizes and which issue the everyday certificates. Software looks up which roots to accept in its own trust store, the list of CAs it considers reliable, and browsers, operating systems and some programming languages each keep their own. That is why a CA is not just another supplier but a trust dependency: when it fails, every system that recognizes it goes down with it.

See also: SSL/TLS certificate · The digital file that encrypts a site's traffic and authenticates its domain, but does not certify the site is trustworthy.

Who decides which CAs to trust

The common rules come from the CA/Browser Forum, which brings together certificate authorities and browser makers: its Baseline Requirements set how a public CA verifies applicants and protects its own keys. Admitting or removing a CA, however, is up to the root programs run by Mozilla, Google, Apple and Microsoft, whose lists serve as the basis for many others. The weakness is structural: any accepted CA can issue certificates for any domain.

When a CA loses trust: eMudhra and Entrust

On October 17, 2026, a researcher reported that the private keys of eight eMudhra intermediate CAs could be recovered: with those keys, anyone could have issued valid certificates for any site and intercepted traffic in a man-in-the-middle attack. eMudhra revoked the eight CAs the next day and attributes the error to a flaw in its key generation, missed by two audits (eMudhra). Mozilla blocked the certificates in Firefox in under three hours (Mozilla), and the root programs distrusted the eMudhra ECC root. But clients that skip revocation checks stay exposed until someone updates the trust store: Go and Python each built a list of certificates to reject into the language itself (CVE-2026-111943, CVE-2026-115557), and Red Hat told customers to rebuild their containers (RHSB-2026-012). Trust can be lost without any compromise, too: in 2024 Chrome stopped accepting new Entrust certificates after six years of compliance failures, and visitors to affected sites saw a full-page warning (Google).

An enterprise example

Picture a company with about twenty microservices in containers and a Python integration with a supplier's ERP system. When a CA is distrusted, employees' browsers update themselves. The containers do not: built on a base image from two years ago, they carry the trust store of that time and keep accepting the distrusted CA until someone rebuilds them. Meanwhile, the cloud services the integration runs through, already updated, reject the supplier's certificate, issued by that very CA, and the integration stalls. The two failures are opposite but have one cause: nobody knew where the trust lists lived or who updated them.

Why it matters for decision makers

The first control is an inventory, kept in a CBOM, of where trust lists live, from container images to cloud services, and of who updates them. The second is a CAA record in DNS (RFC 8659), which lists the CAs allowed to issue certificates for the company's domains: since 2017 public CAs have been required to check it, because the system is only as strong as its weakest CA (CA/Browser Forum). A CAA record does not, however, stop anyone from signing with a stolen key. The third control is a second, already tested CA, so that switching CAs requires no improvising. The fourth is a private CA for internal services, which takes them out of the root programs' hands but makes the security of the private CA's key the company's problem: the eMudhra case shows what is at stake.