How it works
During the TLS handshake the server presents its certificate. It lists the hostnames it covers (in the Subject Alternative Name field, for example example.com and www.example.com or a wildcard such as *.example.com), the public key, the validity period and the signature of the issuing certificate authority (CA). Browsers and mail servers check that the name matches, that the certificate is currently valid and that the signature leads back to a CA they trust.
“SSL certificate” is a leftover name: SSL was retired years ago, and servers now negotiate TLS 1.2 or TLS 1.3. The certificate itself is an X.509 document and does not depend on the protocol version.
The CA/Browser Forum is phasing down the maximum lifetime of public certificates: 200 days since March 2026, 100 days from March 2027 and 47 days from March 2029. Let’s Encrypt already issues short-lived certificates and relies on automated renewal via ACME. Without automation, an expired certificate is only a matter of time.
Why it matters
When the certificate has expired or does not match the name, browsers show a full-page warning such as “Your connection is not private”. Most visitors leave right there, shops lose orders, and APIs, apps and payment providers refuse the connection outright because they never skip certificate errors.
On mail servers the damage is quieter: senders that insist on valid TLS through MTA-STS or DANE stop delivering. Nobody sees an error until customers ask where their mail went.
How to prevent it
- Automate renewal (ACME with Let’s Encrypt or ZeroSSL, or through the hosting panel) and monitor the renewal job instead of tracking expiry dates in a calendar.
- Include every hostname the site answers on, at least the bare domain and www – otherwise even the redirect from the other variant fails.
- After each renewal, verify that the web server was reloaded and actually serves the new certificate rather than just having it on disk.
- Don’t forget mail servers (SMTP, IMAP, submission): their certificates are often managed separately and get left out when the website is automated.
- Disable TLS 1.0 and 1.1 and only use certificates signed with SHA-256 or stronger.
How DomainWarn detects it
The Certificate check performs a TLS handshake on port 443 (or via STARTTLS on a mail port) and reads the expiry date, hostnames, chain, signature algorithm and negotiated protocol. An expired certificate is critical and opens the “Certificate expired” incident immediately; less than 14 days left is a warning with the “Certificate expires soon” incident, less than 30 days a notice. A hostname mismatch, a broken chain or a certificate that is not yet valid leads to “Certificate invalid” after two runs, and a server that does not answer TLS to “TLS unreachable”. SHA-1 signatures and TLS 1.0/1.1 are warnings.
The SMTP check inspects the certificates of the mail servers listed in the MX records via STARTTLS and reports invalid or soon-to-expire certificates (incident “Mail server certificate invalid”). The Subdomain inventory does the same for every known hostname of the domain and catches forgotten subdomains serving a proxy’s default certificate. Every renewal shows up as an event in the timeline, and a change of certificate authority is reported as a warning.
DomainWarn checks this for all your domains on a schedule and alerts you when something is missing or changes.