What does a certificate authority do, and why do browsers trust it?

A certificate authority (CA) is an organization that signs digital certificates, vouching that a public key belongs to the named domain or entity. Browsers and operating systems ship with a list of CAs they trust, so a certificate signed by one of them lets a visitor connect without a warning.

What is actually inside a certificate?

RFC 5280 profiles the X.509 certificate used on the internet. A certificate carries a subject name, the subject's public key, a validity period, the issuer's name, a serial number and extensions, all covered by the issuer's signature. When your browser sees the certificate, it checks that signature, checks that the dates are current, and checks that the name matches the site it asked for.

The trust does not come from the certificate itself. It comes from the chain. A site certificate is signed by an intermediate CA, which is signed by a root CA that the browser already trusts. RFC 5280 describes the path validation procedure that walks this chain from the site certificate up to a trust anchor.

How does a CA know you own the domain?

Historically this verification used a collection of ad hoc mechanisms, as RFC 8555 puts it. That RFC defines ACME, a protocol that lets a CA and an applicant automate verification and issuance. In outline, the applicant asks for a certificate, the CA sets a challenge, such as placing a token at a known URL or in a DNS record, and issues the certificate only if the applicant proves control. ACME also covers revocation.

Automation changed operations. Certificates that once lasted for years and were renewed by hand can now be renewed by software on a schedule, which shrinks the window in which a stolen key is useful.

What happens when a CA makes a mistake or is compromised?

Because any trusted CA can in principle issue a certificate for any domain, a wrongly issued certificate is a serious event. Two mechanisms help.

First, revocation. A CA can publish a certificate revocation list, and RFC 5280 defines the format. Revocation only helps if clients check it, so short lifetimes are often a more dependable control than revocation alone.

Second, Certificate Transparency. RFC 9162 describes public, append only logs of issued certificates, so that anyone can audit CA activity and notice suspect certificates. A domain owner can watch the logs for certificates issued for their names that they did not request.

A constructed example

A company runs shop.example.com. An attacker tricks a weak validation process at a small CA into issuing a certificate for that name. The browser would accept it. But the company monitors transparency logs for its domain, sees an unexpected entry within hours, contacts the CA to revoke it, and rotates anything that depended on the name. Without the log, the certificate could have been used for months unnoticed.

Is the CA model only for websites?

No. Private CAs issue certificates for internal services, devices and workloads. Code signing uses the same idea: a CA binds a signer identity to a key. In software supply chains, short lived certificates tied to an identity, rather than long lived keys, reduce what an attacker gains from a leaked key.

How to check or apply this

1. List every public certificate your organization uses and which CA issued each.
2. Automate renewal with ACME or your platform's equivalent, so expiry is never a manual task.
3. Subscribe to Certificate Transparency monitoring for your domains.
4. Keep an inventory of internal CAs and who can issue from them.
5. Prefer short lifetimes over relying on revocation checks.
6. Document who to call at each CA for an urgent revocation.

Quick check

Sources

• RFC 5280, Internet X.509 PKI Certificate and CRL Profile
• RFC 8555, Automatic Certificate Management Environment (ACME)
• RFC 9162, Certificate Transparency Version 2.0

Last reviewed: 18 October 2026.