So funktioniert’s
Beim TLS-Handshake schickt der Server sein Zertifikat mit. Darin stehen die Hostnamen, für die es gilt (im Feld Subject Alternative Name, etwa example.com und www.example.com oder ein Wildcard wie *.example.com), der öffentliche Schlüssel, der Gültigkeitszeitraum und die Signatur der ausstellenden Zertifizierungsstelle (CA). Browser und Mailserver prüfen, ob der Name passt, ob das Zertifikat gerade gilt und ob die Signatur auf eine CA zurückführt, der sie vertrauen.
Der Name „SSL-Zertifikat“ ist historisch: SSL ist längst abgeschaltet, heute handeln Server TLS 1.2 oder TLS 1.3 aus. Das Zertifikat selbst ist ein X.509-Dokument und hängt nicht an der Protokollversion.
Die maximale Laufzeit öffentlicher Zertifikate sinkt nach einem Beschluss des CA/Browser Forums schrittweise: seit März 2026 auf 200 Tage, ab März 2027 auf 100 Tage und ab März 2029 auf 47 Tage. Let’s Encrypt stellt ohnehin kurze Laufzeiten aus und setzt auf automatische Erneuerung per ACME. Ohne Automatisierung ist ein abgelaufenes Zertifikat nur eine Frage der Zeit.
Warum gefährlich
Ist das Zertifikat abgelaufen oder passt der Name nicht, zeigen Browser eine ganzseitige Warnung wie „Dies ist keine sichere Verbindung“. Die meisten Besucher brechen dort ab, Shops verlieren Bestellungen, und Schnittstellen, Apps oder Zahlungsanbieter verweigern die Verbindung ganz, weil sie Zertifikatsfehler nicht überspringen.
Auf Mailservern ist der Schaden leiser: Absender, die per MTA-STS oder DANE auf gültigem TLS bestehen, stellen keine Mail mehr zu. Eine Fehlermeldung sieht niemand, bis Kunden fragen, wo ihre Mails bleiben.
So vermeidest du es
- Zertifikate automatisch erneuern lassen (ACME mit Let’s Encrypt oder ZeroSSL, alternativ über das Hosting-Panel) und den Erneuerungsjob überwachen, statt Ablaufdaten im Kalender zu pflegen.
- Alle Hostnamen ins Zertifikat aufnehmen, unter denen die Website erreichbar ist, mindestens Domain und www – sonst scheitert schon die Weiterleitung von der anderen Variante.
- Nach jeder Erneuerung prüfen, ob der Webserver neu geladen wurde und das neue Zertifikat wirklich ausliefert, statt es nur auf der Platte liegen zu haben.
- Mailserver (SMTP, IMAP, Submission) mitdenken: Ihre Zertifikate werden oft getrennt verwaltet und bei der Automatisierung der Website vergessen.
- TLS 1.0 und 1.1 abschalten und nur Zertifikate mit SHA-256-Signatur oder besser einsetzen.
So erkennt DomainWarn es
Der Check „Zertifikat“ baut den TLS-Handshake auf Port 443 auf (oder per STARTTLS auf einem Mailport) und liest Ablaufdatum, Hostnamen, Kette, Signaturalgorithmus und ausgehandeltes Protokoll. Ein abgelaufenes Zertifikat ist kritisch und eröffnet sofort den Incident „Zertifikat abgelaufen“; unter 14 Tagen Restlaufzeit gibt es eine Warnung mit dem Incident „Zertifikat läuft bald ab“, unter 30 Tagen einen Hinweis. Ein falscher Hostname, eine ungültige Kette oder ein erst künftig gültiges Zertifikat führen nach zwei Läufen zu „Zertifikat ungültig“, ein Server ohne TLS-Antwort zu „TLS nicht erreichbar“. SHA-1-Signaturen und TLS 1.0/1.1 sind Warnungen.
Der SMTP-Check prüft die Zertifikate der Mailserver aus den MX-Records per STARTTLS und meldet ungültige oder bald ablaufende Zertifikate (Incident „Mailserver-Zertifikat fehlerhaft“). Das Subdomain-Inventar tut dasselbe für alle bekannten Hostnamen der Domain und findet etwa vergessene Subdomains mit dem Standardzertifikat eines Proxys. Jede Erneuerung steht als Ereignis in der Zeitleiste, ein Wechsel der Zertifizierungsstelle kommt als Warnung.
DomainWarn prüft das für alle deine Domains regelmäßig und meldet sich, wenn etwas fehlt oder sich ändert.