| Domain | Aussteller | Läuft ab | Verbleibende Tage | Status |
|---|---|---|---|---|
| mail.example.com | Let's Encrypt | 01.11.2026 | 21 | Läuft bald ab |
| app.example.com | Let's Encrypt | 26.11.2026 | 46 | Gültig |
| shop.example.com | Let's Encrypt | 19.12.2026 | 69 | Gültig |
| example.com | Let's Encrypt | 07.01.2027 | 88 | Gültig |
Automatische Erneuerung hat das Problem größtenteils gelöst und eine leisere Fassung davon geschaffen. Zertifikate erneuern sich jetzt selbst — bis zu dem Tag, an dem sie es nicht tun. Und weil niemand hinsieht, zeigt sich der Fehler als Browserwarnung vor Besuchern statt als Aufgabe auf einer Liste.
Diese Seite listet die Zertifikate, die der Server ausliefert, mit Aussteller, Ablaufdatum und verbleibenden Tagen. Alles unter dreißig Tagen bei einem Zertifikat, das sich automatisch erneuern sollte, heißt: Die Erneuerung scheitert seit einer Weile stillschweigend.
Die üblichen Ursachen lohnt es zu kennen. Die HTTP-Challenge bricht, sobald eine Weiterleitung oder Firewall-Regel /.well-known/acme-challenge/ abfängt. Die Erneuerung gelingt, doch das neue Zertifikat erreicht die Besucher nie, weil der Webserver nicht neu geladen wurde. Eine Domain bleibt in der Zertifikatskonfiguration, nachdem das DNS längst woanders zeigt — und die ganze Erneuerung scheitert an einem veralteten Namen. Von außen sehen alle drei gleich aus: ein Zertifikat, das still auf null zuläuft.
Hier lohnt ein Blick nach Plan statt dann, wenn es einem einfällt: Der Durchlauf der Zertifikate läuft über cron, sodass dreißig Tage Puffer zu einer Warnung werden, lange bevor ein Besucher eine zu sehen bekommt. Ebenso hilfreich ist es, die Zuständigkeitsgrenze zu kennen. Monit meldet, dass der Webserver nicht mehr antwortet, sagt aber nichts über ein Zertifikat mit drei verbleibenden Tagen — ein abgelaufenes SSL legt den Dienst nicht lahm, es legt das Vertrauen des Browsers lahm.