Module 4: Websites and subnetsLesson 12 of 136 min read
How HTTPS certificates work: validation, logs and lifetimes
The padlock in the address bar rests on one file the server sends at the start of every HTTPS connection: its certificate. The browser checks that file in a few milliseconds and either carries on or shows a full-page warning. Knowing what is inside, who vouches for it and how long it lasts explains almost every certificate error, and why renewals are moving from a yearly chore to an automated routine.
What is in a certificate
Cloudflare's guide lists the contents of a certificate: the domain name it was issued for and any additional names, who it was issued to, which certificate authority (CA) issued it, the CA's digital signature, the issue and expiry dates, and the site's public key. The matching private key stays on the server and is never sent.
Devices connecting to the site read the certificate to get the public key and verify the server's identity, checking it against the CA that issued it. If the signature checks out, the name matches the site and the dates are current, the connection goes ahead. A self-signed certificate has no outside authority behind it, so browsers don't trust it.
How a CA checks you control the domain
For a domain-validated certificate, the CA only needs proof that whoever asks controls the domain. Let's Encrypt describes the automated version, the ACME protocol. The client software on the server asks the CA what it must do to prove control of example.com, and the CA offers challenges, such as:
- Provision a DNS record under example.com, or
- Provision a file at a well-known URI on http://example.com/.
Checked from several places
Let's Encrypt notes that this validation can't use HTTPS, since there is no valid certificate yet, which makes it open to certain attacks. To counter that, it validates from multiple network perspectives at once, so an attacker would have to fool several vantage points.
Issuance and the public logs
Once the domain is validated, the client sends a certificate signing request with the public key, signed with the matching private key, and the CA issues the certificate. Let's Encrypt also submits every certificate to numerous public Certificate Transparency (CT) logs.
RFC 9162 explains the purpose. CT logs are append-only lists of issued certificates, built on Merkle trees so that nobody can quietly remove or rewrite an entry. The logs don't prevent mis-issuance, but they make it detectable: domain owners and others can monitor them and spot a certificate for their domain that they never requested. When a log accepts a certificate it returns a signed timestamp, which browsers can require as proof that the certificate was logged.
Reading a checker result for example.com
Issued by: Let's Encrypt. Valid from 2026-10-01, Valid until 2026-12-30: a 90 day certificate. Names covered: example.com, www.example.com. A certificate for example.com only would fail on www.example.com with a name mismatch, even though both are the same site.
Why lifetimes keep getting shorter
Let's Encrypt has issued 90-day certificates since 2015 and offers optional 6-day certificates. Its reasons for short lifetimes are that they limit the damage from mis-issuance and key compromise, and that they push site owners to automate, after which renewal is no less convenient.
Industry rules will limit public certificates to a maximum of 47 days from 15 March 2029. Let's Encrypt's announcement of 7 October 2026 sets its own path: from 10 February 2027, certificates issued or renewed default to 64 days, and the default drops to 45 days in 2028. Existing certificates are not revoked; the last 90-day certificate is expected to expire on 11 May 2027.
When to renew
Let's Encrypt advises renewing at about two-thirds of the lifetime rather than a fixed number of days before expiry. 90 days × 2/3 = 60 days. 64 days × 2/3 ≈ 43 days. 45 days × 2/3 = 30 days. A script that renews 30 days before expiry worked for 90-day certificates (day 60) but would renew a 45-day certificate on day 15.
Common reasons a certificate fails
Four causes are worth checking first when HTTPS fails: the certificate has expired, usually because automated renewal stopped working; the name typed isn't among the names covered; the server sends a certificate that doesn't chain to a trusted CA, as with a self-signed one; or the server still serves an old certificate after a new one was issued, because it was never reloaded. Comparing the newest certificate in the CT logs with what the site actually serves separates the last case from the others.
Check a site's certificate. HTTPS shows Works or Fails, then read Issued by, Valid from and Valid until with its day count, and the list of Names covered. Follow the crt.sh link to see the same certificate in the public CT log.
SSL checkerQuick check
Three questions. Pick an answer to see why.
Why does Let's Encrypt validate a domain from several network locations at once?
Show the answer
Answer: Validation can't use HTTPS, so checking from multiple perspectives makes it much harder for an attacker to fake An attacker would have to intercept traffic on several paths, not one.
What does a Certificate Transparency log let a domain owner do?
Show the answer
Answer: Spot certificates issued for their domain that they never requested Logs are public and append-only, so owners can monitor them for unexpected entries.
Your renewal script runs 30 days before expiry. What happens when certificates become 45 days long?
Show the answer
Answer: It renews on day 15, much earlier than needed 45 − 30 = 15. Renewing at about two-thirds of the lifetime, day 30, is the advice.
Standards, not guesses
These guides explain how the internet's plumbing works, using the published standards (RFCs) and official documentation. Each guide shows the date it was last checked.
Sources
- Cloudflare Learning Center – What is an SSL certificate?
- Let's Encrypt – How It Works
- Let's Encrypt – Certificate Lifetime Rationale and Plans
- Let's Encrypt – 64-Day Certificate Lifetimes Coming Feb 2027
- RFC 9162: Certificate Transparency Version 2.0
Last checked October 28, 2026