What the checker verifies
A valid certificate needs more than an expiry date in the future. The checker rates five things:
- Validity period: has the certificate expired, or does it expire within the next 14 or 30 days?
- Chain: can the certificate be verified through the delivered intermediates up to a trusted root CA? Missing intermediates are the most common cause of warnings on mobile devices.
- Host name: is the requested name listed in the Subject Alternative Name (SAN)? A certificate for example.com does not automatically cover www.example.com.
- Issuer: who issued the certificate? Self-signed certificates are rejected by browsers.
- Protocol: TLS 1.2 or 1.3 are state of the art. TLS 1.0 and 1.1 are considered insecure and rejected by current browsers.
Why certificates expire unnoticed
With Let's Encrypt and 90-day lifetimes, automatic renewal is the norm. It still fails regularly: a changed DNS record, a firewall blocking port 80, an expired API token at the DNS provider, a cron job nobody recreated after the server move. From 2026 browser vendors gradually shorten the maximum lifetime to 47 days; every manually managed certificate becomes a liability.
The outage shows up at the client first: a browser warning, abandoned orders, a phone call on Monday morning. A certificate expiring in 14 days is therefore not a notice but a task.
Common mistakes
- Missing intermediate certificate: desktop browsers often fill it in themselves, mobile devices and older clients do not. Always serve the full chain (fullchain.pem).
- Certificate without www or without the bare domain: include both names in the SAN or use a wildcard certificate.
- Expired certificate on a subdomain: mail server, staging and API often run on their own certificates nobody monitors.
- Wrong certificate after a server move: the new server serves the hosting provider's default certificate because the domain is not assigned yet.
- Certificate from the future: the server clock is wrong and the certificate is "not yet valid".
Checking certificates with openssl
On the command line openssl shows the same information:
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates -issuer -ext subjectAltNameChecking mail server certificates
With the port selector the checker also tests mail servers: 465 (SMTPS) and 993 (IMAPS) speak TLS immediately, while 587 (submission), 143 (IMAP), 110 (POP3) and 25 (SMTP) negotiate it via STARTTLS. Expired mail server certificates are noticed later than website certificates because mail clients show the warning only once and many users click it away. Modern clients and mail servers with MTA-STS nevertheless refuse the connection.
Monitor certificates continuously
DomainWarn checks the certificates of all client domains several times a day, warns 14 days before expiry, detects an issuer change and reports a broken chain before the first visitors see it. The daily digest lists every certificate expiring within the next 30 days.
Frequently asked questions
- Why does my browser show no error while the checker does?
- Browsers cache intermediate certificates and fill in missing links of the chain from their own store. The checker only verifies what the server actually serves, like a mobile device on its first visit.
- How long before expiry should I renew?
- With automatic renewal: Let's Encrypt renews 30 days before expiry. If a certificate drops below 14 days, the automation is broken.
- Does the checker test mail server certificates too?
- Yes. Choose the port next to the domain: 465 and 993 for implicit TLS, 587, 143, 110 and 25 for STARTTLS. Enter the host name of the mail server, not the domain (e.g. mail.example.com).
- What does "host name mismatch" mean?
- The requested name is not in the certificate. Often www or the bare domain is missing, or the server serves a different certificate than expected.