TLS Certificate Expiry and Chain Problems

What a certificate proves

When a browser connects over HTTPS, the server presents a certificate: a signed statement binding a public key to one or more names, valid for a stated period, issued by a certificate authority the browser trusts. The browser checks the signature chain, the validity dates, whether the name it is visiting appears among the certificate's names and, in some setups, revocation status. If any check fails, it warns the visitor or refuses the connection. The checks are independent, which is why one warning page can hide several different faults.

Expiry

Every certificate has a not-before and a not-after date. After the not-after date browsers treat it as invalid. Expiry is the most common failure, and the most preventable. Lifetimes are limited so that mistakes and compromises age out, which makes renewal a routine task that must be automated or diarised.

The DNS Tools SSL Certificate Expiry Checker reports days remaining using fixed thresholds: expired or under seven days is high risk, under 21 days is a medium improvement, and anything beyond passes. Those thresholds are warnings to act well before the date, not an invitation to wait until the last week.

Lapses usually come from process failures: a manual renewal that depended on one person, an automated job that silently stopped when DNS or firewall changes broke its validation step, or a certificate renewed but not installed on every server and load balancer. A secondary hostname that nobody monitors is another favourite.

Hostname mismatch

A certificate lists the names it covers. If you visit a name that is not on the list, the browser rejects it even though the certificate is valid and unexpired. Typical causes are a certificate for example.com that is also served for www.example.com, a wildcard that covers only one label (a certificate for *.example.com does not cover example.com itself or a.b.example.com), and a server that returns its default certificate because the requested name is not configured in its virtual hosts. Check that both apex and www appear among the subject alternative names, and that every address behind the name serves the same certificate.

Incomplete or untrusted chain

Browsers trust a set of root certificates. Servers normally do not use a root to sign a site's certificate directly; they use intermediates. The server must send the leaf plus the intermediates so the client can walk from leaf to a trusted root. If the intermediate is omitted, some browsers may fetch it themselves and appear to work, while other clients such as API libraries, mobile apps, mail servers and monitoring tools fail with a chain error. That inconsistency makes the problem confusing: it works for you and not for others.

A self-signed certificate is its own issuer and chains to nothing a client trusts, so it is fine for a private test and wrong for the public web. An issuer missing from the client's trust store, for instance in an old operating system, produces similar errors for some visitors only. The TLS Checker lists the chain a server sends, with role, subject, issuer and dates, and flags weak keys and signatures.

Clock and other causes

A device or server with the wrong date sees valid certificates as expired or not yet valid. If a single user reports errors that nobody else sees, check their clock before touching the server. Other causes include a certificate installed before its validity start, protocol mismatches where the client and server share no TLS version, and middleboxes that intercept TLS with their own certificate. Revocation is a further reason a seemingly valid certificate is refused; the DNS Tools expiry tool does not check revocation, so a revoked certificate would still show its dates.

Diagnosing step by step

Work from the visible error to the cause rather than reissuing the certificate on a guess.

1. Note the exact error: expired, name mismatch, unknown issuer or incomplete chain. They point to different fixes.
2. Run the HTTPS Checker to see whether the connection succeeds, which address answered and whether verification failed.
3. Run the expiry checker to read the leaf's dates and any intermediates sent.
4. Compare the names on the certificate with the hostname that failed.
5. Test each address behind the name; one stale server in a pool is a common source of intermittent errors.
6. If only some clients fail, suspect the chain or client trust store before suspecting the leaf.

Renewing and replacing safely

Prerequisites: an inventory of everything that terminates TLS for the name (web servers, load balancers, CDNs), access to your certificate authority or ACME client, and the ability to prove control of each name. Risk: a bad installation interrupts HTTPS. Rollback: keep the previous certificate, key and configuration until the new one is verified.

1. Request the new certificate with all required names, apex and www included.
2. Install the leaf with its intermediate certificates on every endpoint, then reload the service.
3. Verify with the TLS and expiry tools, and check from a client that does not fetch missing intermediates, such as a command-line tool.
4. Confirm renewal automation works by watching the next scheduled run, and monitor expiry with a warning well ahead of 21 days.
5. Only then retire the old certificate.

Frequently asked questions

Written by DNS Tools editorial · Last updated 2026-10-09