SSL/TLS certificates explained

The padlock in your browser means the connection to the site is encrypted and the site has shown a valid certificate for its name. This guide explains what that certificate does and doesn't prove, how to read one, and why certificates are getting shorter lives.

SSL or TLS?

"SSL certificate" is the everyday name, but SSL itself is long gone. The IETF said SSL 3.0 "is not sufficiently secure" and must not be used (RFC 7568, 2015). TLS 1.0 and 1.1 were formally deprecated in 2021 (RFC 8996). Today's connections use TLS. The certificates are the same thing whichever name you use.

What a certificate proves

A certificate binds a public key to a name, and a certificate authority (CA) signs it (RFC 5280). Your browser checks that the name you visited is listed in the certificate, that today falls within its validity dates, and that the signature chains back to a CA it trusts.

How much the CA checked depends on the type. The CA/Browser Forum Baseline Requirements define:

• Domain Validated (DV). The CA confirmed that the applicant controls the domain. Apart from an optional country, the certificate holds no details about who runs the site.
• Organization Validated (OV). The certificate also includes a verified organisation name and location.
• Extended Validation (EV). Stricter identity checks under separate EV guidelines.

A padlock tells you the connection is private and the name matches. On its own, it doesn't tell you the business behind the site is trustworthy. Browsers have also stopped highlighting EV. Chrome moved its EV indicator out of the address bar into the Page Info panel in version 77, after Google's research found it didn't protect users as intended. Apple made a similar change to Safari in 2018 (Chromium note).

Reading a certificate

• Issuer – the CA that signed it, usually an intermediate certificate that chains up to a trusted root.
• Validity – "not before" and "not after" dates. After the second date, browsers show an error.
• Subject Alternative Names (SANs) – the list of names the certificate covers. The Baseline Requirements say the SAN extension must be present with at least one name. Putting the name in the older Common Name field is "NOT RECOMMENDED". A wildcard such as *.example.com matches exactly one label, so it covers www.example.com but not example.com or a.b.example.com (RFC 9525).

The SSL certificate panel of your Domain Statistics report shows the certificate's issuer and expiry date.

Certificates are getting shorter lives

In a vote that closed on 11 April 2025, the CA/Browser Forum adopted Ballot SC081v3. All four browser makers voting (Apple, Google, Microsoft and Mozilla) voted yes, as did 25 certificate issuers. None voted against, and five abstained (ballot). The schedule in the Baseline Requirements (version 2.3.0, September 2026) is:

• issued before 15 March 2026: up to 398 days
• 15 March 2026 to 14 March 2027: up to 200 days (the limit in force as of October 2026)
• 15 March 2027 to 14 March 2029: up to 100 days
• from 15 March 2029: up to 47 days

The time a CA may reuse an earlier check of domain control is shrinking on the same dates, from 398 to 200 to 100 and finally to 10 days. The ballot gives the reasons: information in a certificate goes out of date, revocation isn't reliable, and shorter lifetimes make it easier to change cryptography quickly.

Let's Encrypt: free certificates

Let's Encrypt is a free, automated, nonprofit CA. It issues DV certificates only, not OV or EV (FAQ). It has issued 90-day certificates by default since it launched in 2015 (certificate lifetimes). Its published timeline (announcement) is:

• since 13 May 2026: an opt-in profile issues 45-day certificates
• 10 February 2027: the default drops to 64 days
• 16 February 2028: the default drops to 45 days

Six-day (160-hour) certificates have been available on an opt-in basis since January 2026 (six-day certificates). Let's Encrypt warns that renewing at a fixed 60-day interval won't be enough. It recommends that clients use ACME Renewal Information (ARI), or renew about two-thirds of the way through a certificate's life.

HSTS: insisting on HTTPS

HTTP Strict Transport Security (RFC 6797) lets a site tell browsers to use only secure connections from now on:

Strict-Transport-Security: max-age=31536000; includeSubDomains

max-age is in seconds. Browsers ignore the header if it arrives over plain HTTP. Once it's in force, users can't click past certificate errors on the site (MDN). That makes an expired certificate more disruptive, so renewal needs to be reliable.

The first visit is still exposed, because the browser hasn't seen the header yet. The HSTS preload list closes that gap. To join, you need a valid certificate, an HTTP-to-HTTPS redirect, HTTPS on all subdomains, and a header with max-age of at least 31536000, includeSubDomains and preload. Removal from the list "tends to be slow and painful", so be sure first.

Certificate Transparency

Publicly trusted certificates are recorded in public, append-only Certificate Transparency (CT) logs (RFC 9162). The CA gets a signed timestamp (SCT) from each log. According to the CT project, Chrome and Safari require at least two SCTs, depending on the certificate's lifetime. Chrome says all publicly trusted TLS certificates must be CT-compliant to validate (Chrome CT policy).

This has two practical effects:

• You can search CT logs for your domain or subscribe to a monitor to spot certificates you didn't request.
• Every hostname listed in a publicly trusted certificate becomes public, including test and staging names.

A CAA DNS record (RFC 8659) limits which CAs may issue for your domain. The Baseline Requirements have made CAA checking mandatory for CAs since September 2017.

How to check a certificate yourself

1. Run the domain through the Domain Statistics lookup and look at the SSL details.
2. In a browser, click the padlock or site information icon and open the certificate details.
3. From a terminal, use the openssl command below to print the issuer, dates and names.
4. Make sure renewal is automated and monitored. With a 200-day maximum now and 47 days from 2029, manual renewal gets harder to keep up with, and Let's Encrypt advises against it.

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -issuer -dates -ext subjectAltName

For CAA and other record types, see DNS records explained. Dates and limits above were checked against the CA/Browser Forum and Let's Encrypt in October 2026.