SSL-Zertifikat Ablaufdatum prüfen: 4 Wege mit Beispielen

Um das Ablaufdatum eines SSL-Zertifikats zu prüfen, geben Sie die Domain (nur beispiel.de, ohne https://) in unseren kostenlosen SSL-Check ein und lesen die Zeile Läuft ab am. Auf der Kommandozeile liefert openssl s_client zusammen mit openssl x509 -noout -enddate dasselbe Datum als notAfter. Das Tool ist kostenlos, braucht kein Konto und läuft in jedem Browser, ohne Installation.

Hier sind vier Wege zum Ablaufdatum, mit echten Ergebnissen aus Tests vom 29. Oktober 2026. Der zweite Teil zeigt, was das Ablaufdatum nicht verrät: Ein Zertifikat kann innerhalb seiner Gültigkeit liegen und trotzdem eine Browserwarnung auslösen.

Vier Wege, das Ablaufdatum eines SSL-Zertifikats zu prüfen

• Online-SSL-Check: am schnellsten, funktioniert auch am Handy und zeigt das Zertifikat, das der Rest des Internets sieht.
• Browser: gut für einen schnellen Blick auf die gerade geöffnete Seite.
• openssl: der Standard unter Linux, macOS und auf Servern, und skriptfähig.
• curl: praktisch, wenn Sie ohnehin HTTP-Anfragen debuggen.

Methode 1: Ablaufdatum online prüfen

1. Öffnen Sie den SSL-Check.
2. Geben Sie nur den Hostnamen ein: beispiel.de oder shop.beispiel.de. Eine komplette URL kürzt das Tool selbst auf den Host.
3. Lassen Sie den Port für Websites auf 443. Ändern Sie ihn nur für andere TLS-Dienste (siehe unten).
4. Klicken Sie auf Absenden und lesen Sie Läuft ab am. Die Zeiten sind in UTC angegeben.
5. Rechnen Sie die verbleibenden Tage aus und tragen Sie sich mit Puffer eine Kontrolle der Verlängerung in den Kalender ein.

Echtes Beispiel: mybotsy.com

Wir haben unsere eigene Domain durch den SSL-Check geschickt. Das ist die Ausgabe (Zeiten in UTC):

So lesen Sie das Ergebnis:

• Läuft ab am ist das notAfter-Datum des Zertifikats. Am 29. Oktober blieben noch 53 Tage.
• Von Ausgestellt am bis Läuft ab am sind es genau 90 Tage, die typische Laufzeit automatisch ausgestellter Zertifikate.
• Organisation, Allgemeiner Name und Land beschreiben den Aussteller, nicht Ihre Website. WE1 ist eine Zwischen-CA von Google Trust Services. Ihre Domain muss unter „Allgemeiner Name“ also nicht auftauchen. Welche Namen das Zertifikat abdeckt, sehen Sie im Browser oder mit openssl (weiter unten).
• Der Status wird grün, wenn das heutige Datum zwischen den beiden Daten liegt. Geprüft werden nur die Daten (dazu gleich mehr).

Warum Google Trust Services? mybotsy.com läuft hinter Cloudflare. Besucher erhalten daher das Edge-Zertifikat von Cloudflare, das Cloudflare bei öffentlichen CAs wie Google Trust Services bezieht. Nutzt Ihre Website ein CDN, zeigt jeder öffentliche Check das CDN-Zertifikat. Das Zertifikat auf Ihrem Ursprungsserver hat ein eigenes Ablaufdatum und muss separat geprüft werden.

Mailserver und andere Ports

Über das Port-Feld prüfen Sie Dienste, die ab dem ersten Byte TLS sprechen. Wir haben smtp.gmail.com auf Port 465 (SMTP über TLS) getestet: ausgestellt am 7. Oktober 2026, läuft ab am 30. Dezember 2026, Aussteller Google Trust Services WE2. Weitere Ports mit direktem TLS sind 993 (IMAP) und 995 (POP3). Ports, die unverschlüsselt starten und per STARTTLS umschalten, etwa 587 oder 143, brauchen openssl s_client -starttls smtp (bzw. imap), weil der Check sofort TLS erwartet.

Methode 2: Im Browser nachsehen

Jeder Browser zeigt das Zertifikat der geöffneten Seite. Die Bezeichnungen ändern sich je nach Version etwas, der Weg ist aber ungefähr dieser:

• Chrome und Edge: Klicken Sie auf das Symbol links neben der Adresse, dann auf Verbindung ist sicher und Zertifikat ist gültig. Das Ablaufdatum steht beim Gültigkeitszeitraum.
• Firefox: Schloss, Verbindung sicher, Weitere Informationen, Zertifikat anzeigen. Das Enddatum steht im Abschnitt zur Gültigkeit (im englischen Viewer Not After).
• Safari: Schloss, Zertifikat einblenden, dann das Ablaufdatum in den Details.

Der Browser listet auch die alternativen Antragstellernamen (SAN) auf, also die exakten Hostnamen, die das Zertifikat abdeckt. Der Haken: Sie sehen nur das Zertifikat, das Ihr Browser bekommen hat. Mit CDN, Load Balancer oder einem alten Zertifikat auf einem von mehreren Servern können andere Besucher etwas anderes erhalten.

Methode 3: Mit openssl prüfen

Unter Linux, macOS oder Windows (WSL oder Git Bash) verbindet sich dieser Befehl mit dem Server und zeigt beide Daten an:

echo | openssl s_client -connect mybotsy.com:443 -servername mybotsy.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

Unsere Ausgabe:

subject=CN=mybotsy.com
issuer=C=US, O=Google Trust Services, CN=WE1
notBefore=Sep 23 07:23:13 2026 GMT
notAfter=Dec 22 08:21:51 2026 GMT

Sie stimmt sekundengenau mit dem Online-Check überein. Zwei Details sind wichtig:

• Immer -servername angeben. Damit wird SNI gesendet, das einem Server mit vielen Websites sagt, welches Zertifikat Sie wollen. Ohne SNI kann ein Shared Hoster das Zertifikat einer anderen Website liefern, und Sie lesen das falsche Datum.
• echo | schließt die Verbindung sofort, damit der Befehl nicht auf Eingaben wartet.

Mit -ext subjectAltName im zweiten Befehl sehen Sie die abgedeckten Namen. Für mybotsy.com kam DNS:mybotsy.com, DNS:*.mybotsy.com heraus.

Warnung vor dem Ablauf: -checkend

-checkend erwartet eine Anzahl Sekunden und beendet sich mit Exit-Code 1, wenn das Zertifikat innerhalb dieser Frist abläuft. Ideal für Cronjobs und CI:

... | openssl x509 -noout -checkend 2592000   # 30 Tage
Certificate will not expire                 (Exit-Code 0)

... | openssl x509 -noout -checkend 7776000   # 90 Tage
Certificate will expire                     (Exit-Code 1)

Beide Zeilen stammen vom selben mybotsy.com-Zertifikat mit 53 Tagen Restlaufzeit. Für die nächsten 30 Tage ist es sicher, für die nächsten 90 nicht.

Eine Domainliste mit Resttagen prüfen

Schreiben Sie einen Host pro Zeile in hosts.txt und führen Sie aus:

while read -r host; do
  end=$(echo | openssl s_client -connect "$host:443" -servername "$host" 2>/dev/null \
    | openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)
  if [ -z "$end" ]; then echo "$host  no certificate"; continue; fi
  days=$(( ( $(date -d "$end" +%s) - $(date +%s) ) / 86400 ))
  echo "$host  $end  $days days left"
done < hosts.txt

Unser Ergebnis:

mybotsy.com  Dec 22 08:21:51 2026 GMT  53 days left
expired.badssl.com  Apr 12 23:59:59 2015 GMT  -4217 days left
wrong.host.badssl.com  Dec 28 20:02:55 2026 GMT  60 days left

date -d ist GNU-Syntax. Unter macOS installieren Sie coreutils und nehmen gdate -d. Eine Zertifikatsdatei auf der Platte lesen Sie direkt mit openssl x509 -in cert.pem -noout -enddate.

Mit curl

curl -svI https://mybotsy.com 2>&1 | grep -i "expire date" gab expire date: Dec 22 08:21:51 2026 GMT aus. curl lehnt außerdem ungültige Zertifikate ab: Bei expired.badssl.com und wrong.host.badssl.com endete es mit Exit-Code 60 (Zertifikatsproblem), was sich in Skripten leicht abfragen lässt.

Was ein gültiges Ablaufdatum nicht beweist

Wir haben die absichtlich kaputten Testhosts von badssl.com geprüft, um zu zeigen, was ein Datumscheck erkennt und was ihm entgeht.

Abgelaufen: wird erkannt

expired.badssl.com zeigte im SSL-Check einen roten Status, ausgestellt am 9. April 2015, abgelaufen am 12. April 2015. openssl bestätigte: Verify return code: 10 (certificate has expired).

Falscher Hostname: Daten erkennen ihn nicht

wrong.host.badssl.com zeigte einen grünen Status mit Ablauf am 28. Dezember 2026, und doch lehnen Browser es ab. Mit -verify_hostname wrong.host.badssl.com meldete openssl Verify return code: 62 (hostname mismatch). Das Zertifikat deckt *.badssl.com und badssl.com ab, und ein Wildcard gilt für genau eine Ebene. www.badssl.com ist abgedeckt, wrong.host.badssl.com mit zwei Ebenen vor der Domain dagegen nicht.

Defekte Kette: Daten erkennen sie auch nicht

Mit openssl lieferte self-signed.badssl.com Code 18 (selbstsigniertes Zertifikat), untrusted-root.badssl.com Code 19 und incomplete-chain.badssl.com Code 21 (erstes Zertifikat nicht verifizierbar). Code 21 ist der Klassiker: ein fehlendes Zwischenzertifikat. Manche Desktop-Browser gleichen das selbst aus, viele Apps, API-Clients und ältere Smartphones scheitern aber.

Fazit: Das Ablaufdatum hilft bei der Planung der Verlängerung. Ob ein Zertifikat wirklich gültig ist, zeigt erst die Prüfung, ob der Name abgedeckt ist und ob openssl mit -verify_hostname Verify return code: 0 (ok) meldet oder curl fehlerfrei durchläuft.

Zertifikate werden immer kurzlebiger

Der Ballot SC-081v3 des CA/Browser Forums begrenzt öffentliche TLS-Zertifikate, die ab dem 15. März 2026 ausgestellt werden, auf 200 Tage. Am 15. März 2027 sinkt die Grenze auf 100 Tage, am 15. März 2029 auf 47 Tage. Die meisten von uns geprüften Zertifikate liegen schon deutlich darunter: 90 Tage bei mybotsy.com und beim Let's-Encrypt-Zertifikat von badssl.com, 84 Tage beim SMTP-Server von Gmail. Einmal im Jahr von Hand zu verlängern funktioniert nicht mehr. Automatische Verlängerung (ACME-Clients wie Certbot oder das Auto-SSL Ihres Hosters bzw. CDNs) ist Standard, und der Blick aufs Datum bestätigt, dass die Automatik noch läuft.

Ablauf naht? Die Checkliste zur Fehlersuche

• Verlängert, aber das alte Datum erscheint noch? Der Webserver liefert womöglich noch das alte Zertifikat aus. Nginx und Apache laden Zertifikate beim Start oder Reload, also laden Sie den Dienst nach der Verlängerung neu und prüfen Sie jeden Server hinter dem Load Balancer.
• Hinter einem CDN? Prüfen Sie Edge-Zertifikat (jeder öffentliche Check) und Ursprungszertifikat getrennt.
• Automatische Verlängerung scheitert? Ein CAA-Eintrag, der Ihre CA nicht zulässt, blockiert die Ausstellung. Prüfen Sie ihn mit dem DNS-Lookup und unserer Anleitung zum Prüfen von DNS-Einträgen.
• Nicht mit dem Domain-Ablauf verwechseln. Die Domainregistrierung hat ein eigenes Datum, das Sie im Whois-Lookup sehen. Läuft die Domain aus, hilft auch ein gültiges Zertifikat nichts.
• Nach der Reparatur prüfen Sie mit dem Weiterleitungs-Checker, ob http:// auf https:// umleitet, und suchen im HTTP-Header-Check nach dem Header strict-transport-security.

Prüfen Sie Ihres jetzt: Öffnen Sie den SSL-Check, geben Sie Ihre Domain ein und notieren Sie das Datum unter Läuft ab am. Kostenlos und ohne Anmeldung, genau wie der HTTP/2-Check und die anderen Website-Tools.

Häufig gestellte Fragen

Wie finde ich heraus, wann mein SSL-Zertifikat abläuft?

Geben Sie Ihre Domain in den kostenlosen SSL-Check von My Botsy ein und lesen Sie die Zeile Läuft ab am, angegeben in UTC. Im Terminal führen Sie openssl s_client mit -servername aus und leiten die Ausgabe an openssl x509 -noout -enddate weiter, um das notAfter-Datum zu sehen.

Was passiert, wenn ein SSL-Zertifikat abläuft?

Browser zeigen eine ganzseitige Warnung, in Chrome etwa Dies ist keine sichere Verbindung, und die meisten Besucher springen ab. Apps, API-Clients und Tools wie curl verweigern die Verbindung ganz. Behoben ist das erst, wenn ein neues Zertifikat installiert und der Server neu geladen ist.

Wie lange ist ein SSL-Zertifikat gültig?

Öffentliche Zertifikate, die seit dem 15. März 2026 ausgestellt werden, gelten höchstens 200 Tage. Die Grenze sinkt im März 2027 auf 100 und im März 2029 auf 47 Tage. Viele, etwa von Let's Encrypt oder Google Trust Services, laufen bereits nur rund 90 Tage.

Warum zeigt meine Website nach der Verlängerung das alte Datum?

Meist wurde der Webserver nicht neu geladen, ein Server hinter dem Load Balancer hat noch die alte Datei, oder Sie sehen das CDN-Zertifikat statt des Ursprungszertifikats. Laden Sie den Server neu und prüfen Sie erneut mit -servername.

Heißt ein gültiges Ablaufdatum, dass mein SSL funktioniert?

Nicht unbedingt. Ein Zertifikat innerhalb seiner Laufzeit kann scheitern, wenn es den Hostnamen nicht abdeckt oder die Kette unvollständig ist. Prüfen Sie mit openssl -verify_hostname oder curl und achten Sie auf den Verify-Code 0.

Ist der SSL-Check kostenlos?

Ja. Er ist kostenlos und braucht kein Konto. Ohne Anmeldung haben Sie mehrere kostenlose Prüfungen pro Tag, und ein kostenloses My-Botsy-Konto hebt das Tageslimit auf.