SSL-Zertifikatsprüftool

Überprüfen Sie SSL/TLS-Zertifikatsgültigkeit, Ablaufdatum und Zertifikatskette online

Domain

Port

Geben Sie einen Domainnamen ein und klicken Sie auf "Prüfen", um SSL-Zertifikatsinformationen anzuzeigen

Was ist der SSL-Zertifikat Prüfer?

Der SSL-Zertifikatsprüfer untersucht, ob die TLS-Zertifikatskonfiguration einer Website gültig, zur Domain passend und noch nicht abgelaufen ist. Er ist wichtig, weil HTTPS nicht nur ein Schloss-Symbol im Browser ist, sondern die verschlüsselte Verbindung, Serverauthentifizierung und das Vertrauen von Nutzern, Suchmaschinen und Integrationen beeinflusst. Das Werkzeug hilft bei Betrieb, Deployment, Sicherheitsprüfung und Incident-Analyse, indem es Ablaufdatum, Aussteller, Domainnamen, Zertifikatskette und Protokollhinweise sichtbar macht. Typische Probleme sind vergessene Erneuerungen, falsche Intermediate-Zertifikate, nicht abgedeckte Subdomains oder Zertifikate, die auf der falschen Umgebung installiert wurden. Sicherheitsrelevante Ergebnisse sollten nie isoliert bewertet werden; Schlüssel, Kontext, Algorithmus und Vertrauensquelle gehören zur Prüfung.

Anleitung

So wird’s benutzt

Die zu prüfende Domain eingeben (z. B. google.com)
Der Standardport ist 443. Bei besonderen Konfigurationen kann er angepasst werden.
Auf die Schaltfläche „Prüfen“ klicken oder Enter drücken, um die Prüfung zu starten.
Gültigkeitsdauer, Ablaufdatum, TLS-Protokollversion und weitere Details des Zertifikats anzeigen.
Zertifikatskette aufklappen, um Details zu jedem Zertifikat einzusehen – darunter Aussteller, Signaturalgorithmus, SANs u. v. m.

Zertifikat-Tipps

Den exakten Hostnamen prüfen, den Nutzer aufrufen, einschließlich Subdomains. Ein Zertifikat kann für einen Namen gültig sein, für einen anderen jedoch nicht.
Prüfungen nach Änderungen an DNS, CDN, Load Balancer oder Erneuerung erneut durchführen – Zertifikatsketten können je nach Umgebung abweichen, selbst wenn die Domain gleich bleibt.

Anwendungsfälle

HTTPS-Zertifikatszustand vom Backend prüfenGeben Sie eine Domain und einen Port ein, um eine signierte SSL-Zertifikatsprüfung über die Netzwerk-API durchzuführen. Nur der eingegebene Host:Port wird kontaktiert, und es werden keine anderen Endpunkte oder unzugehörigen Hosts während der Prüfung erreicht. Das Ergebnis meldet Handshake-Erfolg, Protokoll, Cipher Suite, Gesamtgültigkeit, Ablaufstatus, verbleibende Tage und Domain-Übereinstimmung.

Die Zertifikatskette inspizierenWenn der Handshake erfolgreich war, können Sie jedes Zertifikat aufklappen, um Subject, Issuer, Seriennummer, Signaturalgorithmus, Gültigkeitsdaten, SAN-Einträge und Selbstsigniert- oder Abgelaufen-Kennzeichnungen anzuzeigen. Das ist nützlich für die Diagnose defekter Intermediate-Ketten, zur Identifikation der tatsächlich ausstellenden CA und zum Erkennen eines versehentlich falsch eingerichteten Zertifikats.

Erneuerungs- und Hostnamenprobleme frühzeitig erkennenDie Statusleiste hebt ungültige Zertifikate, abgelaufene Zertifikate, bald ablaufende Zustände und Domain-Abweichungen hervor. Das ist hilfreich vor DNS-Umstellungen, CDN-Migrationen, Load-Balancer-Änderungen und routinemäßigen Zertifikatserneuerungen. Vergleichen Sie den Ablaufcountdown mit Ihrem Erneuerungsfenster (Let's Encrypt 90 Tage, kommerziell 1-3 Jahre), bevor die Browserwarnung erscheint.

SAN-Abdeckung bei Subdomain-Migrationen prüfenNach dem Handshake zeigt die SAN-Liste jeden Hostnamen an, für den das Zertifikat gültig ist. Vergleichen Sie sie mit Ihrem Subdomain-Inventar, bevor Sie den DNS auf einen neuen Host umstellen, denn ein Wildcard-Zertifikat deckt möglicherweise interne Staging-Hosts oder regionale Subdomains nicht ab, und ein Multi-Domain-SAN kann bei der Neuausstellung einen Eintrag verloren haben. Moderne Browser ignorieren das veraltete Subject-CN-Feld für die Hostnamen-Zuordnung und verlassen sich ausschließlich auf die SAN-Erweiterung – ein Zertifikat mit korrektem CN, aber fehlendem SAN löst in Chrome, Firefox und Safari trotzdem einen Domain-Mismatch-Fehler aus, obwohl ältere Prüftools es als gültig melden könnten.

Intermediate-Kette nach einer CA-Migration validierenWenn Sie die Certificate Authority wechseln oder zu einem neuen Ursprung migrieren, klappen Sie jedes Zertifikat in der Kette auf, um Issuer, Signaturalgorithmus (z. B. SHA-1 vs. SHA-256) und Gültigkeitsdaten zu prüfen. Ein unvollständiges Intermediate-Bundle ist eine häufige Ursache für Handshake-Fehler unter Linux, aber nicht unter macOS – prüfen Sie das Bundle daher von derselben Client-Klasse, die Ihre Nutzer verwenden. Die Kette muss in der Reihenfolge Blatt -> Intermediate(s) -> Root geordnet sein, und Roots müssen nicht übertragen werden, da sie im Client-Trust-Store eingebunden sind. OCSP Stapling hängt bei Aktivierung ein aktuelles Widerrufsstatus-Objekt an den TLS-Handshake an, sodass der Client den OCSP-Responder der CA nicht selbst abfragen muss.

Technisches Prinzip

SSL/TLS-Zertifikate folgen dem X.509-Standard. Jedes Zertifikat enthält diese Schlüsselfelder: Subject (die Domain oder Organisation des Inhabers), Issuer (die ausstellende CA), Validity (Not Before / Not After Daten), Subject Public Key Info (öffentlicher Schlüssel und Algorithmus), Signaturalgorithmus (wie SHA256-RSA oder ECDSA-SHA256) und X509v3-Erweiterungen (von denen die wichtigste die Subject Alternative Name-Erweiterung ist). Beim TLS-Handshake sendet der Server seine Kette in der Reihenfolge: Blattzertifikat → Zwischenzertifikat(e) → Stammzertifikat (das im Browser eingebaut ist und nicht gesendet werden muss). Der Client beginnt beim Blatt, prüft auf jeder Ebene, dass der Issuer dem Subject des übergeordneten Zertifikats entspricht, verifiziert die Signatur des untergeordneten Zertifikats mit dem öffentlichen Schlüssel des übergeordneten, prüft das Gültigkeitsfenster und läuft letztlich bis zu einem vertrauenswürdigen Stammzertifikat zurück. Let's Encrypt stellt Zertifikate aus, die nur 90 Tage gültig sind und für die Automatisierung mit Tools wie certbot konzipiert sind; kommerzielle Zertifikate dauern in der Regel 1 bis 3 Jahre. SNI (Server Name Indication) ermöglicht es einer einzelnen IP, mehrere HTTPS-Sites zu hosten: Der Client sendet zuerst die SNI-Erweiterung während des Handshakes, um dem Server den Zielhostnamen mitzuteilen, und der Server gibt das passende Zertifikat zurück. OCSP (Online Certificate Status Protocol) ermöglicht Echtzeitabfragen darüber, ob ein Zertifikat widerrufen wurde, und vermeidet das Herunterladen umfangreicher CRL-Listen.

X.509-Zertifikatsfelder: Subject (Inhaber), Issuer, Validity, öffentlicher Schlüssel, Signaturalgorithmus und die SAN-Erweiterung
Zertifikatsketten-Validierung: beginnt beim Blatt, prüft Issuer → Subject-Übereinstimmung Ebene für Ebene, verifiziert die Signatur des untergeordneten Zertifikats mit dem öffentlichen Schlüssel des übergeordneten und läuft letztlich bis zu einem vertrauenswürdigen Stammzertifikat zurück
Let's Encrypt-Zertifikate sind standardmäßig 90 Tage gültig, kombiniert mit certbot und ähnlichen Tools zur automatischen Erneuerung; kommerzielle Zertifikate dauern in der Regel 1 bis 3 Jahre
SNI (Server Name Indication) ermöglicht es einer einzelnen IP, mehrere HTTPS-Sites zu hosten; der Client erklärt den Zielhostnamen während des Handshakes und empfängt das passende Zertifikat
OCSP wird für Echtzeit-Widerrufsprüfungen verwendet und vermeidet das Herunterladen umfangreicher CRLs; große CAs setzen zudem OCSP Stapling ein
Abgelaufene Zertifikate, schwache Signaturalgorithmen (SHA-1) und unzureichende Schlüssellänge (RSA unter 2048 Bit) lösen in modernen Browsern Sicherheitswarnungen aus

Beispiele

Zertifikat von GitHub prüfen

github.com — Aussteller DigiCert TLS Hybrid ECC SHA384, 67 Tage verbleibend, Protokoll TLS 1.3, SAN enthält github.com und *.github.com

Zertifikat von Google prüfen

google.com — Aussteller WR2 (Google Trust Services), 84 Tage verbleibend, SAN enthält *.google.com und google.com

Eigenes Zertifikat prüfen

blog.example.com — Aussteller Let's Encrypt R10, 23 Tage verbleibend (bald erneuern), Signaturalgorithmus ECDSA-SHA256

FAQ

Was zeigt die Zertifikatsprüfung an?

Die vollständige Zertifikatskette (Leaf, Intermediate, Root), die Gültigkeitsdaten, die ausstellende CA, den Subject Common Name und die Subject Alternative Names, den Signaturalgorithmus, Typ und Größe des öffentlichen Schlüssels, die Seriennummer des Zertifikats und ob die Kette zu einer vertrauenswürdigen Root passt. Unser Backend verbindet sich mit dem Host auf Port 443 und meldet die Kette, die es sieht.

Kann ich Zertifikate auf anderen Ports als 443 prüfen?

Ja – gib host:port an (z. B. example.com:8443). Manche Builds prüfen auch IMAP (993), SMTP (465/587), POP3 (995) und andere TLS-Ports. Das Protokoll muss reines TLS oder ein von der Seite unterstütztes STARTTLS verwenden.

Was bedeutet 'läuft in N Tagen ab'?

Das notAfter-Datum im Zertifikat. Nach diesem Datum weigern sich moderne Browser, die Seite zu laden. Richte automatische Erneuerung mindestens 30 Tage vor Ablauf ein. Let's-Encrypt-Zertifikate sind 90 Tage gültig – die meisten Betreiber erneuern automatisch nach 60 Tagen.

Warum sieht mein Zertifikat hier gültig aus, scheitert aber im Browser?

Häufige Ursachen: falsche Reihenfolge der Kette (der Server sendet die Intermediates in falscher Reihenfolge); fehlendes Intermediate (der Server sendet nur das Leaf); Root nicht im Trust Store des Browsers (private CA, nicht gebündelte Behörden-CA); SNI-Mismatch (der Server liefert das falsche Zertifikat für deinen Hostnamen). Die Seite weist üblicherweise auf jeden dieser Punkte hin.

Was ist der Unterschied zwischen DV-, OV- und EV-Zertifikaten?

Domain Validation (DV): nur die Domain-Kontrolle wird geprüft. Organization Validation (OV): die Existenz des Unternehmens wird verifiziert. Extended Validation (EV): eine gründlichere Geschäftsprüfung. Moderne Browser zeigen alle drei gleich an (nur ein Schloss-Symbol); EV löst seit 2019 in den meisten Browsern keine grüne Adressleiste mehr aus.

Kann ich ein selbstsigniertes oder Private-CA-Zertifikat prüfen?

Ja. Die Seite zeigt das Zertifikat an, kennzeichnet es aber als 'nicht vertrauenswürdig', weil die CA nicht im öffentlichen Root Store enthalten ist. Praktisch zum Inspizieren eigener Firmen- oder Test-Zertifikate.

Werden Daten des Hosts offengelegt?

Die Prüfung verbindet sich von unserem Backend aus mit dem Host auf Port 443, genau wie jeder andere TLS-Client. Der Host protokolliert diese Verbindung. Führe das nicht gegen Hosts aus, die externe Scans untersagen.