SSL/TLS Certificates Explained: Chains, Expiry and Common Errors.

The padlock in the address bar depends on a small file that expires on a fixed date. When it does - or when the server sends it incorrectly - browsers replace your site with a full-page warning that most visitors won't click through. Understanding how certificates work turns these emergencies into routine maintenance.

Key takeaways

• A certificate binds a domain name to a public key and is signed by a certificate authority (CA).
• Servers must send the full chain (their certificate plus intermediates), not just their own certificate.
• Certificates expire - today usually after 90 days to about a year - and lifetimes keep getting shorter.
• Most errors are expiry, a name mismatch or a missing intermediate.
• Automate renewal and monitor expiry independently, because automation fails silently.

What a certificate contains

• Subject / SANs - the domain names it is valid for, such as example.com and www.example.com, or a wildcard like *.example.com.
• Public key - used during the TLS handshake.
• Validity period - "not before" and "not after" dates.
• Issuer - the CA that signed it.
• Signature - proof the issuer vouches for all of the above.

The chain of trust

Browsers trust a small set of root certificates. Roots rarely sign site certificates directly; they sign intermediate certificates, which sign yours:

Root CA (in the browser's trust store)
  └── Intermediate CA (sent by your server)
        └── www.example.com (your certificate)

Your server must send its certificate and the intermediates. Some browsers fetch a missing intermediate on their own, so the site looks fine on your laptop while phones, API clients and monitoring tools fail. Always configure the "full chain" file.

Inspecting a certificate

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

-servername matters: servers hosting several sites choose the certificate by the requested name (SNI).

Common errors

Why expiry still causes outages

Free, automated certificates made renewal easy - and made it invisible. Typical ways it still fails:

• The renewal job runs but the web server is never reloaded, so it keeps serving the old certificate.
• DNS or firewall changes break the CA's validation (HTTP or DNS challenge).
• The certificate was renewed on one server behind a load balancer but not the others.
• A certificate on a less-visited host (mail, API, admin panel) was forgotten.

Monitoring certificates

An external check sees exactly what clients see, on every host and port:

1. Monitor every hostname that serves TLS - including mail (465/993), APIs and admin panels.
2. Alert 21-30 days before expiry, and again closer to the date.
3. Check the chain and hostname, not just the date.
4. Pair it with domain-expiry monitoring - an expired domain takes the certificate's site with it.

noc724's SSL monitoring checks expiry and validity from outside and warns you by SMS, Telegram or Bale well before the deadline.

Frequently asked questions

• Is SSL the same as TLS?

  +

  SSL is the old protocol name; all secure versions today are TLS. "SSL certificate" is still the common term for a TLS certificate.

• How long are certificates valid?

  +

  Public certificates are now valid for at most about 13 months, and many are issued for 90 days. The industry has agreed to keep shortening maximum lifetimes, which makes automation essential.

• Why does my site work in the browser but fail in curl or an app?

  +

  Usually a missing intermediate certificate. Browsers can fill the gap; most other clients can't. Serve the full chain.