| Domain | Issuer | Expires | Days left | Status |
|---|---|---|---|---|
| mail.example.com | Let's Encrypt | 01.11.2026 | 21 | Expiring soon |
| app.example.com | Let's Encrypt | 26.11.2026 | 46 | Valid |
| shop.example.com | Let's Encrypt | 19.12.2026 | 69 | Valid |
| example.com | Let's Encrypt | 07.01.2027 | 88 | Valid |
Automatic renewal solved most of this problem and created a quieter version of it. Certificates now renew themselves until the day they do not, and because nobody is watching, the failure surfaces as a browser warning in front of visitors rather than as a task on a list.
This page lists the certificates the server presents, with issuer, expiry date and days remaining. Anything under thirty days on a certificate that should be renewing automatically is a signal that renewal has been failing silently for a while.
The usual causes are worth knowing. The HTTP challenge breaks when a redirect or firewall rule starts intercepting /.well-known/acme-challenge/. Renewal succeeds but the new certificate never reaches visitors because the web server was not reloaded. A domain stays in the certificate configuration after DNS has moved elsewhere, so the whole renewal fails on one obsolete name. All three look identical from outside: a certificate quietly running down to zero.
This is worth checking on a schedule rather than whenever it comes to mind: the certificate sweep runs from cron, so thirty days of margin turn into a warning long before a visitor ever sees one. It also helps to know where the boundary lies. Monit will tell you the web server stopped answering, but it will say nothing about a certificate with three days left — an expired SSL does not bring the service down, it brings the browser's trust down.