What Is a Certificate Authority?

Published 2026-08-21

A certificate authority (CA) is a trusted organisation that issues the digital certificates browsers use to confirm a website is who it claims to be and to set up the encrypted HTTPS connection. Every padlock in your address bar traces back to a CA that checked the site controlled its domain and then vouched for it by signing its certificate. That vouching is what “web trust” is built on — and it is thinner than most people assume. In the August 2026 defaults.exposed census of 432,127,908 domains, 3.3 million served self-signed certificates that skip a CA entirely and fail browser trust, and among the small minority of domains that publish a CAA record — the DNS control that names which CAs are allowed to issue for them — 98.9% leave issuance completely unrestricted. This guide explains what a CA does, how the chain of trust works, and how to check which authority signed your own certificate.

If you have ever seen a browser refuse to load a site with a red “Your connection is not private” warning, you have watched the trust chain fail in real time. The certificate authority is the institution that chain depends on, and understanding it turns those warnings — and the padlock that replaces them — from mystery into something you can check and fix. The figures throughout come from the defaults.exposed August 2026 census, an independent scan of 432,127,908 domains graded as of 2026-08-16.

What a certificate authority actually does

A certificate authority performs one job with two halves: it verifies identity, then binds that identity to a cryptographic key by issuing a signed certificate. The certificate is an X.509 document (the format defined in RFC 5280) that states, in effect, “the public key inside this file belongs to the operator of yourbusiness.com.” The CA stakes its own reputation on that statement by signing the certificate with its private key.

That signature is the whole point. Your browser does not trust your website directly — it has never met it. Instead, your browser ships with a root store: a pre-installed list of a few dozen certificate authorities its makers have audited and decided to trust. When a site presents a certificate, the browser checks whether it was ultimately signed by one of those trusted roots. If yes, the padlock appears. If no, you get a warning.

CAs do not operate on the honour system. To keep a root in Chrome, Firefox, Safari, or the Windows store, an authority must pass annual audits and follow the CA/Browser Forum Baseline Requirements — a shared industry rulebook governing how identity is checked, how keys are protected, and how fast a mis-issued certificate must be revoked. How defaults.exposed grades whether a served certificate is currently valid and trusted is documented in the certificate validity methodology.

Trust here is a privilege that can be revoked. Browser and OS vendors have distrusted major certificate authorities before — removing their roots after audit failures or mis-issuance — and when a root is distrusted, every certificate beneath it stops being trusted at the same moment. That is the ultimate backstop of the system: the authorities that vouch for the web are themselves accountable to the software vendors who decide which roots ship. It is also why “a CA signed it” is a meaningful statement and not a rubber stamp — the CA has something real to lose.

The chain of trust: root, intermediate, leaf

Trust does not flow in a single hop. It runs down a chain with three links, and understanding the chain is the fastest way to understand every certificate error you will ever see.

Root certificate. At the top sits the CA’s root — a self-signed certificate whose private key is the anchor of everything below it. Roots are extraordinarily valuable, so they are kept offline in hardware security modules and almost never used to sign day-to-day certificates. Compromising a root would let an attacker forge any website; that is why they are guarded like nuclear material.
Intermediate certificate. The root signs one or more intermediate CAs, and those intermediates do the actual work of signing customer certificates. If an intermediate is compromised, it can be revoked and replaced without disturbing the root or the millions of certificates chaining to it. This is defence in depth applied to trust itself.
Leaf certificate. At the bottom is your end-entity or “leaf” certificate — the one for yourbusiness.com that the browser actually receives.

When a browser connects, the server sends the leaf plus any intermediates. The browser then walks the chain: leaf signed by intermediate, intermediate signed by root, root already in the trust store. If every link verifies and none is expired or revoked, trust is established. A single missing intermediate — a common misconfiguration — breaks the chain even when the certificate itself is perfectly valid. The signature algorithm that makes each link verifiable is graded in the certificate signature algorithm methodology.

There is also a public audit layer over the whole system: Certificate Transparency (CT). Every publicly trusted certificate must be logged in append-only, independently operated CT logs at issuance, and browsers refuse certificates that lack proof of logging. This turns issuance into a matter of public record — anyone, including you, can watch the logs for certificates issued in their domain’s name and catch a mis-issuance the same day it happens. CT does not stop a bad certificate from being created, but it guarantees the bad certificate cannot be created in secret, which is often enough to get it revoked fast.

How a CA verifies you before issuing (DV, OV, EV)

Before a CA signs anything, it must confirm you are entitled to a certificate for that name. There are three validation levels, and they prove very different things.

Domain Validation (DV) proves only that the requester controls the domain — nothing about who they are. The CA issues a challenge: place a specific token at a URL on the site (an HTTP-01 challenge), or publish a specific DNS record (a DNS-01 challenge). If the token appears, control is proven and the certificate issues, often within seconds. The vast majority of the encrypted web now runs on DV, because it is free and fully automatable via the ACME protocol (RFC 8555).

Organisation Validation (OV) adds a check of the legal entity behind the domain — company registration, address, and phone verification — so the certificate carries a vetted organisation name. Extended Validation (EV) goes further still, with a rigorous manual identity process defined by the CA/Browser Forum.

To make domain validation harder to spoof, CAs increasingly perform the check from several network vantage points at once — multi-perspective validation — so an attacker who hijacks the path to one validator cannot fake control. Combined with ACME automation, this is what makes free, instant, trustworthy DV certificates possible at internet scale.

There is a practical wrinkle worth knowing: browsers no longer give OV or EV certificates a distinct visual badge. Years ago an EV certificate lit up a green company name in the address bar; today all three levels show the same neutral padlock, because studies found users did not notice or act on the difference. The validation level still appears inside the certificate’s details, and OV and EV remain useful for machine-readable identity and some regulated contexts — but for the average visitor, a DV certificate and an EV certificate look identical. That is why the padlock should be read as “encrypted and authentic domain,” never as “vetted, reputable business.”

It is worth being clear about what none of these levels prove: a DV certificate says nothing about whether a site is honest or safe. A phishing site can obtain a valid DV certificate for its own look-alike domain in under a minute. The padlock means the connection is encrypted and the domain name is authentic — not that the business behind it is trustworthy. That distinction is one the census makes vivid, because encryption is now nearly universal while good configuration is not.

CAA records: telling CAs who is allowed to issue

By default, any publicly trusted CA in the world can issue a certificate for your domain. That is convenient and also a risk: if any one of dozens of authorities is tricked or compromised, it can issue a certificate for a name it should never touch. CAA — Certification Authority Authorization (RFC 8659) — is the DNS record that closes this gap.

A CAA record is a small entry you publish in your domain’s DNS that names exactly which CAs are permitted to issue for you. Before issuing, a compliant CA is required to look up your CAA record and refuse if it is not on the list. Publishing issue "letsencrypt.org", for example, tells every other authority to decline. It costs nothing, breaks nothing, and shrinks your attack surface from “any CA on earth” to “the ones I chose.”

Almost nobody uses it — and among those who publish something, most do not use it to restrict anything. In the August 2026 census, 98.9% of domains that publish a CAA record still leave issuance effectively unrestricted, meaning the record is present but does not actually constrain which authority may issue. We report the full CAA picture in CAA records: 98.9% of domains never restrict their CA, and the grading rules are in the CAA record methodology.

The governance angle — how few authorities issue for how much of the web — is the subject of the twin report, One CA to Rule Them All: the certificate monoculture report. CAA is not a silver bullet: it only binds compliant authorities, and it does nothing about a certificate already issued. But paired with Certificate Transparency monitoring, it is the cheapest available way to shrink the set of parties who can create a trusted certificate in your name from “anyone” to “the ones you named.”

The Let’s Encrypt monoculture and 90-day certs

The reason the encrypted web exists at the scale it does is automation. Let’s Encrypt, launched as a free, automated DV authority, made certificates a background utility rather than an annual purchase — and it issues the single largest share of publicly trusted certificates on the web today. Automation via ACME is what let HTTPS jump from a minority of sites to the default.

That success brought a structural question: when one authority underpins so much of the web, the health of that one authority becomes everyone’s problem. A monoculture is efficient and fragile in the same breath — an outage, a mass-revocation event, or a trust incident touches a very large fraction of sites at once. This concentration, and what it means for resilience, is exactly what the twin report measures.

Automation also reshaped certificate lifetimes. Let’s Encrypt pioneered the 90-day certificate, and short lifetimes are now the industry direction of travel: the CA/Browser Forum has agreed a schedule that ratchets the maximum certificate lifetime down over the coming years, ending near 47 days. Short lifetimes limit the damage window of a stolen key and force the renewal automation that keeps certificates from silently expiring — which is precisely where so many sites still fail. We cover the trend in detail in The 90-Day Web: certificate lifetimes in 2026.

One side effect of automation-at-scale is heavy reliance on wildcard certificates: 28.5% of the TLS-evaluable web (a population of 231,991,983 domains) is served under a wildcard, which covers every subdomain of a name with one certificate and one key. Wildcards are convenient, but they concentrate risk — a single compromised key exposes every host it covers, and a wildcard cannot itself be constrained to individual subdomains. The pull toward one authority, short lifetimes, and broad wildcard keys is the same pull in three forms: efficiency at the cost of diversity.

When trust breaks: self-signed and expired certificates

The chain of trust has two common failure modes, and the census counts both across hundreds of millions of domains.

Self-signed certificates skip the CA entirely. Instead of an authority vouching for the site, the site vouches for itself — the certificate is signed with its own key, chaining to no trusted root. Cryptographically the connection can still be encrypted, but the browser has no basis to trust the identity, so it throws a full-page warning. Self-signed certificates are legitimate inside a lab or on internal tooling; on a public site they mean visitors are trained to click through security warnings, which is the exact behaviour attackers exploit. The census found 3.3 million domains serving self-signed certificates, measured in Self-signed certificates: the 3.3 million domain census.

Expired certificates are worse in one respect: the site once had proper trust and let it lapse. An expired certificate produces the same alarming browser warning as a self-signed one, usually because renewal automation was never set up or quietly broke. Every expired certificate is a small outage — legitimate users are blocked or taught to ignore the warning. The census found 5.2 million domains still serving certificates that have already expired, detailed in Expired SSL certificates: 5.2 million sites still serving. How defaults.exposed flags a certificate approaching or past its expiry is set out in the certificate expiry methodology.

A third, quieter failure is revocation. When a private key is stolen or a certificate is mis-issued, the CA can revoke it before its natural expiry — publishing that fact through Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP). The catch is that revocation checking has always been unreliable in practice: browsers often “soft-fail,” treating an unreachable status responder as acceptable rather than blocking. This is one of the strongest arguments for the industry’s shift to short-lived certificates — a certificate that expires in weeks limits the damage of a compromised key far more dependably than a revocation signal a browser may never see.

Check which CA issued your certificate

You can inspect the authority behind any certificate in a few ways. In a browser, click the padlock, open the certificate details, and read the Issuer field — that names the CA (and the intermediate) that signed the leaf. From a terminal, openssl s_client -connect yourbusiness.com:443 prints the full chain, letting you confirm the intermediate is present and the dates are current. Neither requires access to the server, because certificates, like DNS, are public by design.

The fastest option is a scanner that reads everything at once. Check your domain free at defaults.exposed — it reads your live certificate straight from the connection and tells you which CA issued it, whether the chain is complete and trusted, whether the certificate is self-signed or expired, and whether you publish a CAA record restricting future issuance. It takes about 30 seconds and needs no account. If a check surfaces a broken chain, a lapsed certificate, or an open CAA posture and you want it fixed properly, see how the fix works.

For the transport layer that the certificate secures, the HTTPS availability methodology and TLS version methodology show what else is graded alongside the certificate itself — a valid certificate is necessary but not sufficient, because the same domain still has to redirect HTTP to HTTPS and negotiate a modern TLS version to be genuinely secure.

What this means

For business owners, the certificate authority is the reason a customer’s browser trusts your checkout page instead of warning them away from it. A self-signed or expired certificate does not just look unprofessional — it actively blocks visitors and trains the ones who persist to ignore the very warnings meant to protect them. Getting this right is cheap: a DV certificate is free and automatable, renewal can be hands-off, and a single CAA record narrows who can ever issue in your name. With 3.3 million domains self-signed and 5.2 million serving expired certificates, a large slice of the web is failing a check that costs nothing to pass.

For IT and security teams, the leverage is in the parts most sites ignore. Encryption is nearly solved; governance of issuance is not. Publishing a restrictive CAA record, monitoring Certificate Transparency logs for unexpected issuance, ensuring intermediates are served so the chain never breaks, and automating renewal so nothing lapses — these are the controls that separate a domain that merely has a padlock from one whose trust chain is actually defended. The census shows how rare that combination is: among domains that bother with CAA at all, 98.9% still leave issuance open to any authority on earth.

FAQ

What is a certificate authority? A certificate authority (CA) is a trusted organisation that verifies who controls a domain and then issues a signed digital certificate binding that domain to a cryptographic key. Browsers ship with a built-in list of trusted CAs, so when a site presents a certificate that chains back to one of them, the browser shows a padlock instead of a warning. The CA is the third party that lets two strangers — your browser and a website it has never met — establish trust. In the August 2026 census of 432,127,908 domains, 3.3 million skipped a CA entirely with self-signed certificates and failed that trust check.

How do SSL certificates work? An SSL/TLS certificate binds your domain name to a public key and is signed by a certificate authority. When a browser connects over HTTPS, the server presents the certificate; the browser verifies the CA’s signature, walks the chain up to a trusted root, checks the dates and revocation status, and — if all pass — uses the certificate’s key to negotiate an encrypted session. The certificate proves identity; the key exchange provides encryption. You can confirm your own in seconds: Check your domain free at defaults.exposed, which reads the live certificate and flags a broken chain, self-signed certificate, or lapsed expiry.

Is Let’s Encrypt a trusted CA? Yes. Let’s Encrypt is a fully trusted, publicly audited certificate authority whose roots are in every major browser and operating system. It issues Domain Validation certificates for free and automates issuance through the ACME protocol, which is why it grew to issue the largest share of certificates on the web. A Let’s Encrypt certificate produces exactly the same padlock as a paid one; the difference is that it validates domain control only (not organisation identity) and uses short 90-day lifetimes that assume automated renewal. Its scale is also why certificate-issuance concentration — a monoculture — has become a topic worth measuring.

What is a certificate chain? A certificate chain is the ordered path of trust from a website’s certificate up to a root the browser already trusts. It has three tiers: the root certificate (self-signed, kept offline, pre-installed in browsers), one or more intermediate certificates (signed by the root, used for day-to-day issuing), and the leaf or end-entity certificate for the actual domain. A browser trusts the leaf only if it can verify each signature up the chain to a trusted root, with no link expired or revoked. A frequent real-world failure is a server that omits its intermediate, breaking an otherwise valid chain.

What happens if a certificate authority is compromised or distrusted? If a CA is compromised or repeatedly mis-issues, browser and OS vendors can remove its root from their trust stores. The moment that happens, every certificate chaining to that root stops being trusted, so affected sites must obtain new certificates from a still-trusted authority. This has happened to major CAs in the past and is the system’s ultimate accountability mechanism. You can reduce your own exposure to a single authority’s failure by publishing a CAA record naming the CAs you use and by watching Certificate Transparency logs — yet in the August 2026 census, 98.9% of domains with a CAA record left issuance unrestricted, forgoing that protection.

Data to cite

“98.9% of domains that publish a CAA record do not actually restrict which CA may issue for them.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“3.3 million domains serve self-signed certificates — bypassing certificate authorities entirely and failing browser trust.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“Public issuance is a near-monoculture: Let’s Encrypt dominates, with 90-day certificate lifetimes now the norm.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“5.2 million domains are still serving certificates that have already expired.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“28.5% of the TLS-evaluable web — a population of 231,991,983 domains — is served under a wildcard certificate, concentrating many hostnames behind a single key.” — defaults.exposed August 2026 Domain Security Census (432M domains)

See where your own domain stands

A certificate authority answers one question for every visitor you have: can this site be trusted enough to show a padlock instead of a warning? For millions of domains the honest answer is no — the certificate is self-signed, expired, or served without its intermediate, and most owners have never seen it stated plainly because they never checked the issuer.

Check your domain free at defaults.exposed — it reads your live certificate from the connection and tells you which CA issued it, whether the chain is complete and trusted, whether the certificate is self-signed or already expired, and whether you publish a CAA record that restricts future issuance. Takes 30 seconds. No account needed. If you want the gaps closed properly — a trusted certificate, a complete chain, automated renewal, and a locked-down CAA posture — see how the fix works.

Read the flagship census report: The State of Domain Security 2026 →

Aggregate data only. Data stored and processed in the EU.

Data source: defaults.exposed August 2026 census, methodology v9, as of 2026-08-16. 432,127,908 domains scanned; certificate and CAA findings drawn from the TLS-evaluable population of 231,991,983 domains. All figures are counts of graded domains. References: RFC 5280 (X.509), RFC 8659 (CAA), RFC 8555 (ACME), RFC 8446 (TLS 1.3).

How to cite this report

Press / blog: defaults.exposed (2026). What Is a Certificate Authority (CA)? How Web Trust Works. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/v9/articles/what-is-a-certificate-authority

Academic: defaults.exposed. (2026, August 21). What Is a Certificate Authority (CA)? How Web Trust Works. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/v9/articles/what-is-a-certificate-authority

In-line citation: (defaults.exposed, August 2026 Domain Security Census, n=432,127,908 domains scanned)

About the defaults.exposed August 2026 Census

The defaults.exposed Domain Security Census is a recurring independent measurement of the public domain namespace. The August 2026 edition scanned 432,127,908 domains between 1–16 August 2026 and graded them using methodology v9. Certificate, chain-of-trust, and CAA findings are drawn from the TLS-evaluable population of 231,991,983 domains. Scans are conducted from EU infrastructure. No individual domain, registrant, or business is named in any report. All figures are aggregate distributions. Data is stored and processed within the EU.

Methodology: defaults.exposed/v9/methodology Full census report: defaults.exposed/en/articles/the-state-of-domain-security-2026

Data sourced from the August 2026 grading methodology (v9) — 34 checks, 376 million domains. Browse the census statistics or the Census Explorer, or see all August 2026 research →