SSL-Zertifikat abgelaufen: Was passiert und wie Sie es schnell beheben

Ein abgelaufenes SSL-Zertifikat bedeutet: Das Zertifikat, das die Identität Ihrer Website belegt, hat sein Ablaufdatum überschritten, und Browser vertrauen ihm ab diesem Moment nicht mehr. Besucher sehen statt Ihrer Inhalte eine bildschirmfüllende Warnung wie NET::ERR_CERT_DATE_INVALID, API-Clients und Mobile-Apps fallen komplett aus, und der Traffic bricht ein, bis das Zertifikat ersetzt ist. Die Lösung: Zertifikat erneuern oder neu ausstellen, die neue vollständige Kette auf jedem Server installieren, der TLS terminiert, und die Dienste neu laden; mit einer automatisierten ACME-Einrichtung dauert das wenige Minuten. Diese Anleitung zeigt, wie Sie das Ablaufdatum prüfen, ein abgelaufenes Zertifikat Schritt für Schritt reparieren und dafür sorgen, dass es nie wieder passiert.

Was Besucher sehen, wenn Ihr SSL-Zertifikat abgelaufen ist

Browser erwähnen das Problem nicht dezent am Rand. Sie ersetzen Ihre komplette Seite durch einen Warnbildschirm, und der Besucher muss sich durch ein "Erweitert"-Menü klicken, um überhaupt weiterzukommen. Der Wortlaut unterscheidet sich je nach Browser:

Diese Warnungen sind häufig genug, um sie im großen Maßstab zu messen. In der größten veröffentlichten Studie zu Zertifikatswarnungen analysierten Forscher von Google und der Carnegie Mellon University über 300 Millionen Chrome-Warnmeldungen und führten 4,23 % der Warnungen unter Windows auf Datumsfehler des Zertifikats zurück (Acer et al., ACM CCS 2017). Abgelaufene Zertifikate sind der Routine-Fehlerfall von HTTPS, und die Warnseite selbst ist oft das erste Signal, das der Betreiber bekommt.

Es bricht mehr als nur die Startseite

Die Browserwarnung ist nur der sichtbare Teil. Die stillen Ausfälle kosten meist mehr:

• APIs und Webhooks fallen hart aus. Maschinen-Clients haben keinen "Erweitert"-Button. Zahlungs-Callbacks, Mobile-Apps, Partner-Integrationen und Monitoring-Agenten verweigern die Verbindung in der Sekunde, in der das Zertifikat abläuft.
• HSTS entfernt den Notausgang. Sendet Ihre Website den HSTS-Header, blendet der Browser den Link "trotzdem fortfahren" komplett aus. Besucher können sich nicht durchklicken, selbst wenn sie wollten.
• E-Mail und interne Tools stehen still. TLS für SMTP, IMAP und Admin-Panels fällt genauso hart aus, und genau diese Zertifikate hat niemand im Blick.
• Vertrauen erodiert am schnellsten. Ein Unternehmen mit abgelaufenem Zertifikat auf der eigenen Website ist ein Widerspruch, den Besucher sich merken. Suchmaschinen sehen denselben Warnzustand, und konversionsstarke Seiten verlieren ihren Traffic, solange die Warnung steht.

Drei berühmte Ausfälle durch ein einziges abgelaufenes Zertifikat

Zertifikatsablauf ist kein Problem kleiner Firmen. Einige der teuersten Ausfälle des vergangenen Jahrzehnts hatten genau diese Ursache:

Die Lehre ist unbequem: Diese Unternehmen beschäftigen Weltklasse-Ingenieure, und das Zertifikat lief trotzdem ab. Erneuerung ist ein Prozessproblem, kein Kompetenzproblem, und eine Kalendererinnerung in irgendeinem Postfach ist kein Prozess.

So prüfen Sie, wann Ihr Zertifikat abläuft

Drei Wege, vom schnellsten zum gründlichsten:

1. Im Browser. Klicken Sie auf das Schloss- oder Einstellungssymbol in der Adressleiste, öffnen Sie "Verbindung ist sicher" und dann "Zertifikat ist gültig". Das Detailfenster zeigt den exakten Gültigkeitszeitraum.

2. Über die Kommandozeile. Fragen Sie das aktive Zertifikat mit OpenSSL ab:

openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

Die Ausgabe zeigt notBefore und notAfter; die zweite Zeile ist Ihre Frist.

3. Prüfen Sie die ganze Kette, nicht nur Ihr eigenes Zertifikat. Auch Zwischen- und Root-Zertifikate laufen ab. Als das Root-Zertifikat AddTrust External CA Root am 30. Mai 2020 ablief, fielen weltweit Dienste mit völlig gültigen Serverzertifikaten aus, darunter Roku-Geräte und mehrere Zahlungsplattformen. Ein externer Scan, der die komplette Kette validiert, findet, was der schnelle Blick aufs eigene Zertifikat übersieht.

Abgelaufenes SSL-Zertifikat beheben, Schritt für Schritt

Schritt 1: Bestätigen Sie, dass wirklich der Ablauf die Ursache ist. Führen Sie den OpenSSL-Befehl oben aus und lesen Sie notAfter. Ist das Zertifikat in Wahrheit gültig, geht die Geräteuhr des Besuchers falsch, und auf Ihrem Server muss nichts repariert werden.

Schritt 2: Erneuern oder neu ausstellen. Mit Let's Encrypt oder einem anderen ACME-Client ist die Erneuerung ein einziger Befehl (sudo certbot renew), und ein Probelauf (sudo certbot renew --dry-run) verrät vorab, ob die Validierung gelingen wird. Bei einer kommerziellen CA erzeugen Sie im Kundenportal einen frischen CSR und schließen die Validierung dort ab.

Schritt 3: Installieren Sie die vollständige Kette überall, wo TLS terminiert wird. Das neue Zertifikat muss jeden Endpunkt erreichen, der für die Domain TLS spricht: Ursprungsserver, Load Balancer und die CDN-Edge. Verteilen Sie fullchain.pem (Serverzertifikat plus Zwischenzertifikate), nicht das Serverzertifikat allein, sonst tauschen Sie einen Datumsfehler gegen einen Kettenfehler.

Schritt 4: Laden Sie den Dienst neu. Eine erneuerte Datei auf der Festplatte ändert nichts, bis der Server sie neu einliest. Führen Sie sudo systemctl reload nginx aus (oder das Gegenstück für Apache, HAProxy oder Ihre Plattform). Das ist der häufigste Fehler in "automatisierten" Setups: Der Erneuerungs-Cron läuft perfekt, der Reload-Hook wurde nie eingerichtet, und der Server liefert das alte Zertifikat weiter aus dem Speicher.

Schritt 5: Verifizieren Sie von außen. Prüfen Sie von einem Smartphone im Mobilfunknetz, einem frischen Browserprofil oder einem externen Scanner. Zertifikate kennen keine Propagationsverzögerung: In dem Moment, in dem der Server neu geladen ist, erhält jede neue Verbindung das neue Zertifikat.

Die Erneuerung wird bald unerbittlich

Wenn sich Erneuerung heute beherrschbar anfühlt: Der Zeitplan ändert sich gerade unter Ihren Füßen. Mit dem CA/Browser-Forum-Beschluss SC-081v3, im April 2025 einstimmig mit 29 zu 0 Stimmen angenommen, sank die maximale Laufzeit öffentlicher TLS-Zertifikate am 15. März 2026 von 398 auf 200 Tage, fällt am 15. März 2027 auf 100 Tage und landet am 15. März 2029 bei 47 Tagen (CA/Browser Forum). Let's Encrypt geht bereits weiter: Im Dezember 2025 kündigte die Organisation an, die Standardlaufzeit von 90 auf 45 Tage zu senken, und ihre Sechs-Tage-Zertifikate sind seit dem 15. Januar 2026 allgemein verfügbar.

Zertifikatslaufzeiten, die 2026 angeboten und erlaubt sind. Quellen: CA/Browser Forum, Beschluss SC-081v3; Let's Encrypt.

Die Richtung ist eindeutig: Erneuerungen, die früher einmal im Jahr anstanden, stehen bald alle sechs bis sieben Wochen an, bei kurzlebigen Zertifikaten alle paar Tage. Manuelle Erneuerung überlebt diesen Takt nicht. Automatisierung hört auf, ein Nice-to-have zu sein, und wird zum einzigen Weg, ein Zertifikat gültig zu halten.

So läuft nie wieder ein Zertifikat ab

• Automatisieren Sie Ausstellung und Erneuerung mit ACME, und richten Sie den Deploy-Hook ein, der den Webserver nach jeder Erneuerung neu lädt.
• Überwachen Sie Ablaufdaten von außen. Ein externer Check findet jedes Zertifikat, das ein Erneuerungsskript still übersprungen hat. Alarmieren Sie 30, 14 und 7 Tage vor Ablauf.
• Inventarisieren Sie jedes Zertifikat, nicht nur die Hauptseite: API-Subdomains, Mailserver, Staging-Umgebungen und interne Panels laufen nach eigenen Zeitplänen ab.
• Behandeln Sie die Erneuerung wie ein Deployment. Sie ändert, was die Produktion ausliefert, und verdient denselben Verifikationsschritt wie ein Code-Release.

Verwandte Leitfäden

• SSL/TLS-Zertifikatssicherheit: der komplette Leitfaden zur A+-Bewertung behandelt Protokolle, Ketten und Konfiguration über das Ablaufdatum hinaus.
• "Ihre Verbindung ist nicht privat": Was der Fehler bedeutet und wie Sie ihn beheben erklärt die Warnseite, die Ihre Besucher gerade sehen.
• ERR_CERT_AUTHORITY_INVALID: Ursachen und wie Sie den Fehler beheben behandelt die Kettenfehler, die oft direkt nach einer übereilten Erneuerung auftauchen.
• Was ist HSTS? erklärt, warum manche Besucher Zertifikatswarnungen gar nicht umgehen können.

FAQ

Können Besucher meine Website öffnen, solange das Zertifikat abgelaufen ist? In den meisten Browsern können sie sich über ein "Erweitert"-Menü durchklicken, aber die Mehrheit tut es nicht, und wenn Ihre Website HSTS sendet, entfernt der Browser diese Option komplett. API-Clients und Apps verweigern die Verbindung sofort.

Schadet ein abgelaufenes SSL-Zertifikat der SEO? Indirekt ja. Crawler sehen dasselbe ungültige Zertifikat, Besucher springen an der Warnseite ab, und HTTPS ist ein bestätigtes Rankingsignal. Je länger die Warnung steht, desto mehr Traffic und Vertrauen gehen verloren.

Wie lange dauert die Reparatur? Mit eingerichteter ACME-Automatisierung: Minuten. Erneuern, neu laden, verifizieren. Es gibt keine Propagationszeit, denn das neue Zertifikat wird sofort nach dem Neuladen an jede neue Verbindung ausgeliefert.

Warum lief mein Zertifikat ab, obwohl die automatische Erneuerung aktiv war? Die üblichen Ursachen: Die Erneuerung lief, aber kein Reload-Hook war eingerichtet, also blieb das alte Zertifikat im Speicher; die Validierung schlug nach einer DNS- oder Firewall-Änderung still fehl; oder die Erneuerung deckte einen anderen Hostnamen ab als das Zertifikat, das tatsächlich ablief.

Sind abgelaufene Zertifikate auf internen Tools wichtig? Ja. Interne und API-Zertifikate fallen genauso aus wie öffentliche, werden aber weniger überwacht. Mehrere der Vorfälle in diesem Artikel begannen mit einem Zertifikat, das niemand inventarisiert hatte.

Prüfen Sie Ihre Zertifikate, bevor es Ihre Besucher tun

Ein Ablaufdatum verhandelt nie. Starten Sie einen kostenlosen FortifyNet-Scan und sehen Sie das exakte Ablaufdatum Ihres Zertifikats, die vollständige Kette, die Protokollkonfiguration, Sicherheitsheader, DNS und E-Mail-Authentifizierung in rund 60 Sekunden. Ohne Registrierung.

---

Quellen: CA/Browser Forum, Beschluss SC-081v3; Let's Encrypt, Certificate Lifetimes; Let's Encrypt, 6-Tage-Zertifikate GA; The Register zum Ericsson-Ausfall; TechCrunch zum Teams-Ausfall; Data Center Dynamics zum Spotify-Ausfall; Acer et al., "Where the Wild Warnings Are", ACM CCS 2017.