Every time a padlock appears in your browser, an invisible third party has quietly vouched for the site you're visiting. That third party is a certificate authority, or CA — the organization that issues the SSL/TLS certificate proving a website is who it claims to be. CAs are the reason two computers that have never met can set up an encrypted, authenticated connection in milliseconds. This guide explains what a certificate authority actually does, why your browser trusts one in the first place, how a CA decides whether to issue you a certificate, and what happens on the rare occasion a CA loses that trust.
In short
A certificate authority is a trusted organization that verifies who controls a domain, then issues and digitally signs an SSL certificate binding that domain to a public key. Browsers and operating systems ship a trust store of pre-approved CA root certificates, so any certificate that chains back to one of them is trusted automatically. CAs operate under the CA/Browser Forum Baseline Requirements and independent audits — and a CA that breaks the rules can be distrusted and removed.
What a certificate authority is
A certificate authority is a trusted third party that issues digital certificates. In the context of the web, that means SSL/TLS certificates: small signed documents that bind a public key to a verified identity, usually a domain name. When a CA issues a certificate for example.com, it is making a checkable claim — "we verified that the holder of this certificate controls example.com" — and staking its own reputation on that claim by signing the certificate with its private key.
The reason CAs exist comes down to a problem encryption alone can't solve. Encryption scrambles data so eavesdroppers can't read it, but it says nothing about who you're talking to. You could establish a perfectly encrypted connection — to an impostor. The missing ingredient is authentication: proof that the server on the other end really is the bank, shop, or service you intended to reach. A CA supplies that proof. It's the part of public key infrastructure (PKI) that turns "this connection is encrypted" into "this connection is encrypted and I know who I'm encrypting it with."
A useful analogy: a CA is like a passport office. You can't reasonably verify a stranger's identity yourself, but you both trust the government that issued their passport — so the passport becomes a portable proof of identity that anyone can check. An SSL certificate is a website's passport, and the CA is the office that issued it. Your browser checks the "passport" on every connection, without you having to do a thing.
Why your browser trusts a CA
A CA's signature is only meaningful if your software already trusts that CA. That trust doesn't appear out of nowhere — it comes from a trust store (also called a root store): a curated list of CA root certificates that ships with your browser or operating system. If a website's certificate can be traced back to a root in that store, it's trusted. If it can't, you get the familiar "your connection is not private" warning.
There isn't one universal list — there are several major root programs, each maintained independently:
- Mozilla runs an open root program used by Firefox and, because it's free and transparent, by much of the Linux ecosystem.
- Apple maintains the trust store used by Safari, macOS, and iOS.
- Microsoft maintains the Windows trust store used by Edge and many Windows applications.
- Google ships its own Chrome Root Store with Chrome (rolled out from 2023), so Chrome now applies a consistent trust policy across platforms instead of deferring to the OS.
Getting a root into one of these stores is hard, and staying there is harder. A CA must pass annual independent audits (such as WebTrust), comply with the CA/Browser Forum Baseline Requirements, and — in Chrome's words — show that the value it provides to users clearly exceeds the risk of its continued inclusion. The practical takeaway for a site owner is reassuring: as long as you buy from a CA already in the major trust stores, your certificate will be trusted everywhere out of the box. This is also the foundation that makes the certificate chain work.
How a CA issues a certificate
Issuance follows a consistent sequence, whether you're buying a certificate from a commercial CA or getting a free one through an automated service:
- You generate a key pair and a CSR. On your own server you create a private key (which never leaves your control) and a certificate signing request containing your public key and the domain you want covered.
- The CA validates your control of the domain. This is the heart of the CA's job. At minimum, it confirms you control the domain — typically by asking you to place a specific DNS record or file on the site (domain control validation). Higher tiers add checks on the organization itself.
- The CA checks for permission and prior conditions. It consults your domain's CAA records — DNS entries that name which CAs are allowed to issue for the domain — and refuses if it isn't authorized.
- The CA signs and logs the certificate. Once validation passes, the CA signs your certificate with one of its intermediate keys and submits it to public Certificate Transparency logs (more on that below), then delivers it to you to install.
Notice what the CA never sees: your private key. It only ever receives your public key inside the CSR, which is exactly how it should be — the security of the whole system depends on that private key staying with you. If you'd like to walk the full handshake that uses the finished certificate, our guide on how SSL works covers it step by step.
Validation levels: DV, OV, and EV
Not every certificate involves the same depth of checking. The differences between certificate types come down to how much identity the CA verifies before issuing — not to how strong the encryption is, which is identical across all three.
| Level | What the CA verifies |
|---|---|
| DV (Domain Validation) | Only that you control the domain. Issued quickly, often within minutes and fully automated. This is what free CAs issue. |
| OV (Organization Validation) | Domain control plus the existence and identity of the organization behind it, using business records. Takes longer and involves human review. |
| EV (Extended Validation) | The most rigorous vetting, following a standardized checklist of the legal, physical, and operational existence of the organization. |
The choice of level is really a choice about how much trust you want the CA to assert on your behalf. A blog or personal site is well served by DV; a bank or e-commerce brand often wants the organization name vetted via OV or EV. Our deeper comparisons of certificate types and OV vs EV lay out when each is worth it. If you just need basic HTTPS, a DV certificate — including a free one — is genuinely all you need.
Root CAs, intermediates, and the chain of trust
A CA almost never signs your certificate with the root key that sits in browsers' trust stores. That root is too valuable to expose: its private key is kept offline in a hardware security module, used rarely and under heavy guard. Instead, the root signs one or more intermediate certificates, and those intermediates do the day-to-day work of signing the certificates issued to websites.
The chain in three links
Your certificate is signed by an intermediate CA, which is signed by a root CA that lives in the browser's trust store. A browser follows that chain upward; if it ends at a trusted root, the certificate is accepted. This is why a server must send not just its own certificate but the intermediate(s) too — omit them and clients can't complete the chain.
This layered design isn't just security theater — it's operational insurance. If an intermediate key is ever compromised, the CA can revoke that intermediate and issue a new one without disturbing the root or every certificate beneath it. The single most common real-world SSL misconfiguration is a server that forgets to send its intermediate certificate, which makes the chain look broken to some clients even though the certificate itself is fine. Our guide to the SSL certificate chain explains how to spot and fix that.
What keeps a CA honest
A CA is enormously powerful: a single misissued certificate for a major domain could be used to impersonate it. Several overlapping mechanisms exist precisely to constrain that power and make abuse detectable.
The CA/Browser Forum Baseline Requirements
A shared rulebook, written by CAs and browser makers together, that defines how certificates must be validated, what they may contain, and how long they may live. It's the same rulebook driving recent changes like the move toward shorter certificate lifetimes and stricter domain validation.
Certificate Transparency (CT)
Every publicly trusted certificate must be recorded in public, append-only CT logs, and the CA embeds a Signed Certificate Timestamp (SCT) as proof. Chrome refuses certificates that aren't CT-compliant. The point is openness: because every issuance is logged, a domain owner — or anyone — can monitor the logs and spot a certificate they never asked for, catching misissuance that would once have been invisible.
CAA records and independent audits
A domain's CAA records let you whitelist which CAs may issue for your domain, so a non-authorized CA is contractually obliged to refuse. On top of that, every CA in the root programs undergoes regular third-party audits to confirm it actually follows its stated practices.
When trust is taken away
The ultimate check on a certificate authority is the threat of distrust: a root program removing the CA from its trust store. It is the corporate-death-penalty of the CA world, used sparingly, but its existence is exactly what makes the whole arrangement credible. Trusted status is never permanent — it has to be continually re-earned.
Recent examples
In 2024, Chrome and Mozilla announced they would distrust Entrust after a run of compliance incidents: new Entrust-rooted certificates with a Signed Certificate Timestamp after mid-November 2024 would no longer be trusted by default. Entrust arranged to issue from SSL.com's roots in the interim and later sold its certificate business to Sectigo. In 2025, Chrome 139 distrusted the Chunghwa Telecom and Netlock roots for certificates timestamped after July 31, 2025, again citing unresolved compliance problems.
Two practical lessons fall out of this. First, the system genuinely self-corrects — even a long-established CA can be removed when it stops meeting the bar. Second, for site owners, it's a reminder that the CA you choose is a real dependency: picking a well-run, reputable CA isn't just box-ticking, it's insurance against having to scramble for replacement certificates if your provider ever falls out of favor.
How to choose a certificate authority
Because every publicly trusted CA meets the same baseline, the encryption and the basic "is it trusted?" question are settled before you even choose. What's left to weigh:
- Validation level you need. If a verified organization name matters to your audience, choose a CA that offers solid OV/EV vetting. If you just need HTTPS, any CA's DV product — or a free one — does the job.
- Track record and stability. A CA with a clean compliance history is less likely to be the subject of the next distrust announcement. Reputation is a feature.
- Automation and lifetime fit. With certificate lifetimes shrinking, renewal is now a recurring chore. A CA (or reseller) with good automation — ACME support, APIs, reminders — saves you from expiry-driven outages.
- Support and warranty. Paid CAs typically add human support and a warranty; free CAs don't. Whether that's worth paying for depends on how critical the site is.
If you'd like to see how the major providers stack up, our roundup of the top SSL certificate authorities compares them side by side. And if a free, fully trusted DV certificate is all you're after, our free SSL option issues publicly trusted certificates with automatic renewal — no cost, same trust.
The bottom line
A certificate authority is the trust anchor of the secure web: it verifies identity, signs certificates, and stakes its reputation — under continuous oversight — on each one being legitimate. You rarely think about CAs, and that's the point. When the system works, the padlock just appears. To go a layer deeper, start with what PKI is and how the certificate chain works.