Bridge SSL
What is a certificate authority? What CAs do and why browsers trust them
A certificate authority (CA, also certification authority) is an organisation that verifies who controls a name and then signs an HTTPS certificate saying so. Browsers accept a site's certificate because they trust the authority that signed it, which makes CAs the part of the system that turns an encryption key into a verified identity.
Anyone can sign a certificate. A trusted certificate authority is one that follows public rules, passes independent audits and has its root in browsers' root stores.
- Checks before signing
- control of every name in the request (Baseline Requirements §3.2.2.4) and the domain's CAA records [1][2]
- Never does
- generate a subscriber's key pair for a TLS server certificate (§6.1.1.3) [1]
- Rules and audits
- CA/Browser Forum Baseline Requirements, version 2.3.1; WebTrust or ETSI EN 319 411-1 audits, each covering at most one year (§8.1, §8.4) [1]
What a certificate authority does
It checks the request. Before signing, the authority verifies that the requester controls the name, and for some certificate types that the organisation exists. How much it checks is what separates DV, OV and EV; see certificate types.
It signs the certificate. The signature binds the name to the requester's public key. Anyone holding the authority's public key can confirm the certificate came from it and was not altered.
It publishes certificate status. If a certificate must stop being trusted before it expires, the authority revokes it and publishes that through revocation lists or OCSP; see certificate revocation.
It logs what it issues. Publicly trusted certificates are recorded in public logs, which is how unexpected issuance for a domain becomes visible; see certificate transparency. Chrome refuses a certificate that does not come with proof of logging under its CT policy [6].
An authority does not generate or hold your private key. The key is created on your side, and only the public half goes into the request. For TLS server certificates the Baseline Requirements turn this into a rule: the CA shall not generate the key pair for a subscriber, and shall not accept a request that uses a key it generated earlier [1].
What a certificate authority checks before it signs
Every publicly trusted certificate goes through domain validation. The Baseline Requirements list the permitted methods in §3.2.2.4, and the certificate authority picks one of them for each name [1]. Among them are:
a DNS change (§3.2.2.4.7);
an agreed-upon change to the website through ACME (§3.2.2.4.19);
a TLS response using ALPN (§3.2.2.4.20).
Root programmes can add conditions: the Apple Root Program Policy requires a CA to support at least one of the methods it lists [5].
Two further checks guard against a forged answer. The CA repeats the domain and CAA checks from several network perspectives, which helps protect against a BGP hijack of a single route (§3.2.2.9) [1]. It also reads the domain's CAA records (RFC 8659): if they exist and do not authorise it, it must not issue (§4.2.2.1) [1][2].
A certificate authority can reuse a completed check for a limited time only. For certificates issued since 15 March 2026 a domain validation may be up to 200 days old; the limit falls to 100 days from 15 March 2027 and to 10 days from 15 March 2029 (§4.2.1) [1].
Wildcards and several names
The method matters for wildcards. A certificate authority can validate a name like *.example.com only by a domain validation method the requirements mark for wildcard names, such as the DNS change; the ACME website method and TLS with ALPN are not among them [1]. Every name is validated separately, so a certificate for multiple domains needs proof of control for each one before it is issued.
Root and intermediate authorities
Authorities are layered. A root authority's certificate sits in the trust stores shipped with browsers and operating systems. The root signs intermediates, and the intermediates sign the certificates sites use: the Baseline Requirements forbid signing with a root key except for the root itself, subordinate CAs, OCSP response verification and internal infrastructure [1]. Root CA systems must sit on networks physically separate from the rest of the CA's infrastructure [7]. If an intermediate key is compromised, it can be replaced without touching the root on every device in the world.
An authority that signs from an intermediate is an intermediate certificate authority, and a browser trusts it only through the root above it.
That layering is why a server has to send the intermediate along with its own certificate. A browser holds the roots, receives the site's certificate, and needs the intermediates to connect the two; see certificate chains.
Why browsers trust some authorities and not others
Trust is a list. Each browser and operating system ships a root store, and an authority is trusted exactly when its root is in it. Root programmes decide who gets in, and the CA/Browser Forum sets the baseline requirements publicly trusted authorities must follow: how they validate requests, how long certificates may live, and how they must be audited.
Each programme adds its own policy on top: the Mozilla Root Store Policy (version 3.1), the Chrome Root Program Policy (version 1.8) and the Apple Root Program Policy (version 2.0) [3][4][5]. All three require the Baseline Requirements and audits by independent auditors; Mozilla and Apple ask for a new audit at least once a year [3][5].
An authority that breaks those rules can be removed. Mozilla's policy says it may disable or remove a certificate at any time and for any reason, and Chrome's says it includes or removes certificates at its sole discretion [3][4]. When a root is removed, certificates that chain to it stop being accepted, and every site holding one has to replace it on the browsers' timeline rather than its own.
Public and private certificate authorities
Public authorities are the ones in browser root stores, and their certificates are accepted anywhere. They are the only option for a public website.
A private authority is one an organisation runs itself, for internal services, devices and client certificates. Its certificates are trusted only by machines where its root has been installed, which is exactly what makes it suitable for internal use and unsuitable for anything public. A self-signed certificate is the smallest case of the same idea: an issuer nobody else has agreed to trust.
| Criterion | Public certificate authority | Private certificate authority |
|---|---|---|
| Trusted by | browsers and operating systems out of the box | only devices where its root was installed |
| Rules | Baseline Requirements and root programme policies | its owner's own policy |
| Audits | required by the root programmes | not required by browsers |
| Domain validation | required for every name | up to the owner |
| Fits | public websites | internal services, devices, client certificates |
Running a private authority also means taking on certificate lifecycle management: issuing, renewing and revoking, and getting the root onto every device that has to trust it.
Free and paid authorities
The encryption does not depend on who signed the certificate or what it cost. Free authorities issue domain-validated certificates automatically through ACME; paid authorities add organisation and extended validation, support agreements and other services. Both validate domains under the same Baseline Requirements [1]. How to choose between them is covered on choosing a certificate authority.
How to see which authority issued a certificate
In a browser, open the padlock or site information and view the certificate: the issuer field names the intermediate certificate authority that signed it, and the chain view shows the root. From a terminal:
$ openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -issuerTo see which authorities a domain allows, query its CAA records. The CA uses the closest set it finds walking up from the name towards the root; if there is none, CAA places no restriction [2].
$ dig +short example.com CAAFAQ
What is a certificate authority?
An organisation trusted to verify who controls a domain and to sign certificates saying so. Browsers accept a site's certificate when it chains to a root authority in their trust store.
What does a certificate authority do?
It validates certificate requests, signs certificates, revokes certificates that should no longer be trusted, and publishes their status.
What is a trusted certificate?
One that chains to a root in the client's root store, issued by an authority that follows the Baseline Requirements and passes its audits.
Who regulates certificate authorities?
Browser and operating system root programmes decide which authorities they trust, and the CA/Browser Forum publishes the baseline requirements publicly trusted authorities must meet, including audits.
Can I become my own certificate authority?
Yes, as a private authority: create a root, install it on devices you manage, and issue certificates from it. Its certificates will be trusted on those devices only. Becoming a publicly trusted authority requires audits and acceptance into browser root programmes.
What is a CA certificate?
The certificate of a certificate authority. Its basic constraints extension sets cA to TRUE, so its key may sign other certificates, as defined in RFC 5280, section 4.2.1.9. A root CA certificate is self-signed; an intermediate one is signed by a root. Certificate chains are covered in Root and intermediate authorities above.
Sources
CA/Browser Forum, Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, version 2.3.1: §3.2.2.4, §3.2.2.9, §4.2.1, §4.2.2.1, §6.1.1.3, §6.1.7, §8.1, §8.4.
IETF, RFC 8659, DNS Certification Authority Authorization (CAA) Resource Record.
Mozilla, Mozilla Root Store Policy, version 3.1: §3.1.3 audit parameters, §7.3 removals.
Google, Chrome Root Program Policy, version 1.8: §1.1.1 Baseline Requirements, §1.4 audits.
Apple, Apple Root Program Policy, version 2.0: §1.1 audit requirements.
Google, Chrome Certificate Transparency Policy.
CA/Browser Forum, Network and Certificate System Security Requirements, version 2.0.5.
IETF, RFC 5280, Internet X.509 Public Key Infrastructure Certificate and CRL Profile, §4.2.1.9 Basic Constraints.