Bridge SSL
What is an SSL certificate? Contents and lifecycle
An SSL certificate, more precisely a TLS certificate, is a signed statement that a particular public key belongs to whoever controls a particular name. Everything else about it follows from that: what it contains, which certificate authority is willing to sign it, how long the statement stands, and what happens when it stops being true.
The encryption itself does not need a certificate. What needs one is the question of who you are talking to, and that is the only question a certificate answers.
- Binds
- a public key to one or more hostnames (the subject alternative name list)
- Issued by
- a certificate authority after domain validation; organisation validation adds company checks
- Maximum validity period
- 200 days for publicly trusted certificates issued since 15 March 2026; 398 days for those issued before [1]
- Validity schedule
- 200 days from 15 March 2026, 100 days from 15 March 2027, 47 days from 15 March 2029 [2]
- Key types in use
- at least RSA 2048-bit or ECDSA P-256; the private key is never part of the certificate [3]
- Ends by
- expiry on the stated date, or revocation before it
What a certificate contains
Six things matter to anyone operating a site, and the rest is detail.
The names it covers — A list of hostnames the statement applies to, stored in the subject alternative name field. This is the field browsers compare against, and it is the one that causes the most errors when it does not include what someone typed. One certificate may list several names; a multi domain certificate is nothing more than a long list.
The public key — The half of a key pair that anyone may hold. The private key never appears in the certificate and never leaves your control. Today that pair is at least RSA 2048-bit or ECDSA P-256 [3].
The validity period — A start and an end, after which the statement no longer stands.
The issuer — Which authority signed it. That signature is what connects your certificate, through an intermediate certificate, to a root certificate in the trust store of the browser.
The signature — The authority's cryptographic statement over everything above.
The subject — Historically the primary identifier, now largely vestigial. Browsers read the name list instead; Chrome stopped consulting the common name in version 58 [4].
Server certificate and client certificate
The certificate a web site presents is a server certificate: it tells the client which names the web server answers for, and the SSL certificate described on this page is of that kind. In TLS 1.3 the server must send a Certificate message whenever the key exchange uses certificates for authentication. RFC 8446 adds that the client sends one if and only if the server has requested client authentication, so a certificate on a web server is the server's half of the exchange. How the protocol uses it is covered under TLS/SSL.
A browser message saying that the certificate for this server is invalid is a separate matter: it reports a problem with this certificate, and each message is explained in SSL errors: every browser code explained and fixed.
An SSL certificate for a domain name
An SSL certificate for a domain name carries the domain name as an entry in the subject alternative name extension. RFC 5280 describes the extension as allowing identities to be bound to the subject of the certificate, and lists a DNS name and an IP address among its defined options.
Each domain name is its own entry: example.com and www.example.com are two names, and each one is listed. A wildcard certificate with *.example.com covers one level of subdomains. The authority checks control of the names before signing, as described above. The certificate of a web site binds a key to the name. The SSL certificate and the domain name stay separate things, and a domain name SSL certificate is not a registration of the domain name.
What a certificate authority checks before issuing
Validation is the part that gives a certificate its meaning, and it is narrower than most people assume.
A publicly trusted certificate authority verifies control of the name, and for the common type of SSL certificate that is all it verifies. The public key in the request is signed; the private key is never seen. It does not check who you are, whether your business is legitimate, or whether your site is safe. Demonstrating that you can change what a name resolves to, or place a file where that name serves it, is sufficient. Over ACME this domain validation runs without any human intervention; the authority's software asks, your server answers, nobody reads anything [5].
Two consequences follow.
Anyone who controls a domain can obtain a certificate for it, including someone who obtained that control improperly. A certificate proves control, not virtue.
And whoever controls DNS effectively controls certificate issuance, which is why DNS account security is a certificate concern as much as a naming one.
You can constrain which authorities are permitted to issue for your domain by publishing a CAA record that says so. That record lives in DNS rather than in any certificate; the certificate side of the arrangement is that compliant authorities check it before issuing and refuse if they are not listed.
The certificate of the CA itself, as opposed to yours
A CA certificate is not an SSL certificate for a site. It is the certificate of the authority that signs them. One thing that marks it out is the basic constraints extension, which RFC 5280 defines as identifying whether the subject of the certificate is a CA. Its cA flag says whether the certified public key may be used to verify certificate signatures.
Two kinds sit above yours in the chain: an intermediate certification authority that signs what it issues, and a CA root held in the trust store. The server sends its own certificate first. RFC 8446 lets the sender of a TLS 1.3 certificate chain omit a certificate that specifies a trust anchor, provided supported peers are known to possess it.
Who issues certificates at no charge is on the page about the SSL certificate authority free route.
The lifecycle
A certificate's life has four stages, and most operational trouble happens at the transitions.
Request — You generate a key pair and a certificate signing request stating the names you want covered. The request carries the public key and proves you hold the private one.
Validation and issuance — The authority verifies control and signs. The whole path, from first request to a working certificate, is covered in how to create an SSL certificate.
Service — The certificate is installed on the server and presented to clients together with the intermediates that make up the certificate chain up to a trusted root. Omitting that second half is a frequent installation fault: it works in your own browser, which has cached the intermediate, and fails for fresh visitors and scripts.
Expiry or replacement — The statement ends on schedule and certificate renewal issues a new one; nothing is extended. If a certificate should no longer be trusted before its end date, certificate revocation withdraws it early, and clients learn of this through CRLs or OCSP.
Across a fleet of names, keeping track of all four stages for every certificate is the job of certificate lifecycle management.
Getting an HTTPS certificate
You get an HTTPS certificate for a web site by asking a certificate authority to sign a request for your names. The result is the certificate this page describes; the name HTTPS only says where it is used. You do not make it yourself. You generate a key pair and a signing request, the authority validates control of the domain name and signs, and the SSL certificate for the domain comes back. Over ACME, RFC 8555 requires the message that finalizes an order to include that signing request.
Who issues certificates without charge is covered under free SSL certificates. The steps from key to installed file are kept on generating an SSL certificate, not repeated here.
Choosing between the kinds
SSL certificates differ along two independent axes, and conflating them is the usual source of confusion. Neither axis changes the validity period, which the certificate authority sets within the same ceiling for all of them.
| Axis | Options | What changes | What does not change |
|---|---|---|---|
| Validation | DV, OV, EV | what the authority checked: control of the name only, or the organisation behind it too | encryption strength; the padlock browsers show |
| Coverage | single name, SAN list, wildcard | how many hostnames one certificate covers | the issuance process |
By validation — Domain validation (DV) is automated. Organisation validation (OV) and extended validation (EV) go beyond the name: for OV the authority must verify the identity and address of the organisation [3]. The practical differences, and what browsers do and do not display about them, are on types of SSL certificate.
By coverage — A single name, a list of names, or one level of subdomains. A wildcard certificate for
*.example.commatchesshop.example.com.
A certificate has a position on both axes. Asking "should I use a wildcard or an organisation-validated certificate" is asking two different questions at once.
Whether you pay is a third question, independent of both. Free SSL certificates from Let's Encrypt are domain-validated certificates that browsers trust. A self-signed certificate costs nothing either, but no browser trusts it, which confines it to development and internal use.
What certificates do not do
Four things, each of which someone expects of an SSL certificate and none of which is true.
It does not make a site trustworthy. A TLS certificate states that the name is controlled by whoever holds the key, which says nothing about their intentions.
It does not protect the server. Compromise of the machine is unaffected by the certificate on it, and a compromised server serves attacker content over a perfectly valid encrypted connection.
It does not encrypt anything by itself. The encryption comes from the TLS protocol; the certificate lets you know who you negotiated it with. Nor does it force browsers to use HTTPS at all; that is the job of an HSTS header.
It does not confirm identity in the everyday sense unless the authority checked identity, which for the common type it did not.
Why validity periods keep getting shorter
Certificates have become shorter-lived over the years, and the reasoning is straightforward: revocation does not work reliably. When a certificate must be withdrawn early, telling every client in time is not something the system does well, so the alternative is to limit how long any certificate remains valid in the first place. A short lifetime achieves by expiry what revocation is supposed to achieve by announcement, and it requires no client to check anything.
The numbers are set by the CA/Browser Forum, the body whose Baseline Requirements every publicly trusted authority follows. From September 2020 the ceiling was 398 days. A schedule adopted in April 2025 lowered it to 200 days for certificates issued since 15 March 2026; the Baseline Requirements set 100 days from 15 March 2027 and 47 days from 15 March 2029 [1][2].
The consequence for operators is a shift in what counts as normal. Manual renewal was a plausible practice when certificates lasted years; at a 47-day lifetime it is a task every six weeks with a deadline that produces an outage when missed, and the only sane response is automation. An expired SSL certificate is still the most visible way a site goes dark, and it is entirely self-inflicted.
That is also why questions of the form "how long should I buy for" have become less interesting. Building a process that does not care what the number is protects you from the next change.
Reading a certificate yourself
Every browser lets you inspect the SSL certificate a site presents, including its validity period and certificate chain, through the padlock or the warning page; how to check an SSL certificate walks through Chrome, Firefox and Safari. The fields above are all visible there, and the two worth reading first are the name list and the validity period, because they account for most errors.
For a certificate you hold as a file rather than one being served, OpenSSL can check the certificate: x509 -text renders the same fields and verify checks the chain. Which command you need depends on the certificate format in front of you: PEM, DER, PFX and P7B hold the same certificate encoded differently.
FAQ
What is an SSL certificate?
A file (a TLS certificate, strictly) in which a certificate authority states, under its signature, that a given public key belongs to the controller of a given hostname. Browsers use it to decide whom they are talking to before encrypting anything.
What does a certificate authority actually check?
For a domain-validated certificate, only that you control the name: a DNS record or a file at a URL it specifies. OV and EV certificates add a check of the organisation's legal existence against public registers.
Does a certificate mean a site is safe?
No. It means the connection is to the holder of the key for that name. A phishing site can hold a perfectly valid certificate for its own domain.
Does the certificate provide the encryption?
No. TLS negotiates the encryption; the certificate authenticates one party in that negotiation. Without the certificate you would be encrypting to an unknown peer.
Can I control which authorities may issue for my domain?
Yes, with a CAA record in DNS. Compliant authorities must check it and refuse to issue if they are not listed.
Is an SSL cert the same as a TLS cert? Yes. Both names mean the certificate described on this page, and "TLS" is the precise one, as the opening says. "SSL" is the name of an older protocol, and RFC 7568 requires that SSL 3.0 not be used. For TLS 1.3, RFC 8446 requires the server's certificate to be of type X.509v3 unless another type is explicitly negotiated. What the protocol does with the certificate is explained under TLS/SSL.
What does a website certificate do when someone opens the site? A web site certificate is the SSL certificate the server presents for an https address, and the browser checks whether it is valid for that site. If it is not valid for the origin of the address, RFC 9110 says a user agent must either obtain confirmation from the user before proceeding or terminate the connection with a bad certificate error. Security certificates for websites therefore settle one point, whether the key belongs to the name that was typed. They say nothing about whether the site deserves trust.
Deeper reading
Sources
CA/Browser Forum, Baseline Requirements for TLS Server Certificates, §6.3.2 (version 2.3.1) — maximum validity 200 days for certificates issued on or after 2026-03-15; 398 days for those issued before.
CA/Browser Forum, Ballot SC-081v3, adopted April 2025 — schedule of 200 / 100 / 47 days.
CA/Browser Forum, Baseline Requirements, §3.2.2.1 — verification of organisation identity and address; §6.1.5 — minimum key sizes.
Chrome for Developers, Deprecations and Removals in Chrome 58 — support for commonName matching in certificates removed.
Let's Encrypt, How It Works — ACME obtains browser-trusted certificates without any human intervention.