SSL-Checker
Zertifikatskette, Ablauf und Algorithmus jeder Website prüfen.
- Certificate is valid for this host and not expired.
- example.com
- *.example.com
What does each field mean?
Field reference
Antragsteller (Subject)
Das Subject-Feld identifiziert den Zertifikatsinhaber. Moderne Zertifikate stützen sich auf den CN (Common Name) plus die Subject Alternative Names. Organization (O), Organizational Unit (OU) und Locality (L) sind bei EV/OV-Zertifikaten vorhanden, bei einfachen DV-Zertifikaten (z. B. Let's Encrypt) fehlen sie.
Aussteller (Issuer)
Identifiziert die CA, die für den Antragsteller bürgt. Browser bringen eine Liste vertrauenswürdiger Root-CAs mit; von einer nicht vertrauenswürdigen oder selbst signierten Stelle ausgestellte Zertifikate führen zu NET::ERR_CERT_AUTHORITY_INVALID. Bekannte öffentliche CAs: Let's Encrypt, DigiCert, Sectigo, GlobalSign, GoDaddy.
Subject Alt Names (SAN)
Ein einzelnes Zertifikat kann über die SAN-Erweiterung mehrere Hosts abdecken — typisch für Wildcards (<code>*.example.com</code>) oder Multi-Domain-Zertifikate. Seit 2017 ignorieren Browser den Common Name und prüfen ausschließlich gegen SAN-Einträge. Ist Ihr Host nicht aufgeführt, ist das Zertifikat dafür ungültig.
Kettentiefe
Die Vertrauenskette beginnt beim Leaf-Zertifikat des Servers, führt über ein oder mehrere Intermediate-CA-Zertifikate und endet bei einer Root-CA im Trust-Store des Browsers. Tiefe 2 (Leaf + 1 Intermediate) ist typisch. Vergessen Server, die Intermediates mitzuliefern, sehen Clients "incomplete chain".
Signaturalgorithmus
Beschreibt, wie die CA das Zertifikat signiert hat. <code>sha256WithRSAEncryption</code> (RSA + SHA-256) ist der sichere Standard. <code>ecdsa-with-SHA256</code> nutzt elliptische Kurven — kürzere Schlüssel bei gleicher Sicherheit. <code>sha1WithRSAEncryption</code> gilt seit 2017 als gebrochen und wird von allen großen Browsern abgelehnt.
Öffentlicher Schlüssel
Die öffentliche Hälfte des Schlüsselpaares. RSA 2048 Bit ist heute das praktische Minimum; 3072+ für langlebige Schlüssel. EC P-256 ist kürzer (~256-Bit-äquivalente Stärke) und schneller. Alles unter RSA 2048 oder älter als P-256 sollte ersetzt werden.
Ausgehandelte Cipher Suite
Beschreibt die Verschlüsselung der eigentlichen Nutzdaten: Schlüsselaustausch (ECDHE), Cipher (AES_256_GCM, CHACHA20_POLY1305), MAC (SHA384). Forward-Secrecy-Suites (ECDHE-*) werden von den meisten Sicherheitsstandards verlangt. CBC- oder RC4-basierte Suites sind veraltet.
Hostname-Übereinstimmung
Selbst ein einwandfrei gültiges Zertifikat wird abgelehnt, wenn der angefragte Hostname nicht in der SAN-Liste steht. Wildcards passen auf genau ein DNS-Label: <code>*.example.com</code> deckt <code>www.example.com</code> ab, jedoch NICHT <code>a.b.example.com</code> oder die nackte <code>example.com</code>.
Selbst signiert
Bei einem selbst signierten Zertifikat sind Subject und Issuer identisch. Browser vertrauen ihm nicht — der Fehler lautet "NET::ERR_CERT_AUTHORITY_INVALID". Akzeptabel für interne oder Staging-Umgebungen, in denen Sie Server und Client kontrollieren. Für Produktion: Let's Encrypt (kostenlos) oder eine öffentliche CA.
Gültig bis (Ablauf)
Browser lehnen abgelaufene Zertifikate ohne Ausnahme ab. Zertifikate öffentlicher CAs laufen typischerweise 90–397 Tage. Richten Sie automatische Erneuerung ein: ACME / Let's Encrypt 60 Tage vor Ablauf, kommerzielle CAs 30 Tage vorher. Bis 2027 ist branchenweit eine schrittweise Verkürzung auf 90 Tage Pflicht zu erwarten.
Vollständig gültig
Alle Grundprüfungen bestanden: Die Vertrauenskette endet bei einer browserseitig vertrauten Root, der Hostname steht in den SANs, das Zertifikat liegt im Gültigkeitszeitraum und der Signaturalgorithmus ist akzeptabel. Dieser Zustand entspricht dem grünen Schloss im Browser.
Über dieses Tool
SSL Checker führt einen vollständigen TLS-Handshake gegen einen Host durch und liefert das Zertifikat, seine Chain und die Konfigurationsdetails der Verbindung. Sie sehen: Common Name und SANs, Issuer, Gültigkeitszeitraum, ausstellende CA, Schlüsselgröße und -typ, verwendete Cipher-Suite, TLS-Version, OCSP-Stapling-Status, HSTS-Header und ob das Zertifikat im Browser-Trust-Store als vertrauenswürdig gilt.
Der Check läuft live von unserem Frankfurter Server. Wir parsen das Zertifikat in lesbare Felder, zeigen die volle Chain bis zur Root-CA und kennzeichnen mögliche Probleme: bevorstehender Ablauf, fehlende Intermediates, schwache Cipher, fehlende SANs, abgelaufene Chain-Glieder. Ein Schnellbefund-Banner oben fasst zusammen: alles gut, abgelaufen, ungültiger Hostname, kein Trust, oder schwache Konfiguration.
Wann Sie dieses Tool nutzen sollten
- Vor und nach Cert-Renewal. Bestätigen, dass Let's Encrypt erfolgreich erneuert hat.
- Bei Browser-Warnungen. Was sagt unser unabhängiger Check über die TLS-Konfiguration?
- Compliance-Audit. TLS 1.2 oder höher? Keine schwachen Cipher? Korrekte Chain?
- Pre-Launch-Check. Neue Domain mit HTTPS — alle Komponenten korrekt gesetzt?
Häufige TLS-Fehler
Fehlende Intermediates: Der Server liefert nur das Leaf-Zertifikat, nicht die Chain — manche Browser können trotzdem laden, andere nicht. Hostname-Mismatch: Das Zertifikat ist aufexample.com ausgestellt, Sie greifen auf www.example.com zu, kein passender SAN. Abgelaufenes Zertifikat: Ein Tag zu spät — alle Browser warnen. Schwache Cipher: RC4, 3DES, SHA-1 — heutige Standards sind AES-GCM mit ECDHE-Key-Exchange.
Häufige Fragen
Was sind SANs?
example.com sollte SAN example.com UND www.example.com enthalten. Wildcard-Zertifikate haben SANs wie *.example.com, die für eine Hierarchieebene gelten (aber nicht für foo.bar.example.com).
Was bedeutet "Chain unvollständig"?
fullchain.pem ausgeliefert wird.