Der SSL-Checker oben führt eine vollständige Diagnose an jedem öffentlich zugänglichen SSL/TLS-Zertifikat durch und liefert einen detaillierten Bericht mit Sicherheitsbewertung, Zertifikatskette, Cipher Suites, Schwachstellen-Scans und Browser-Kompatibilität. Die folgenden Abschnitte erklären, wie jeder Teil des Berichts zu lesen ist.
Ihre SSL-Sicherheitsbewertung verstehen
Jeder SSL-Checker-Scan erzeugt eine Buchstabennote von A+ bis F, zusammen mit einem numerischen Punktestand von 100.
- Ein A oder A+ bedeutet, dass das Zertifikat korrekt installiert ist, moderne Kryptografie verwendet und der Server die richtigen Sicherheitsfunktionen aktiviert hat.
- Zertifikate mit der Note B sind funktionsfähig, zeigen aber Verbesserungspotenzial bei der Absicherung.
- C und darunter weisen in der Regel auf eine veraltete TLS-Version, eine fehlende Sicherheitsfunktion oder ein kurz vor dem Ablauf stehendes Zertifikat hin.
Der Punktestand wird über fünf Kategorien gewichtet:
- Zertifikat (Gültigkeit und Algorithmus)
- Vertrauen (anerkannte Certificate Authority und Kettenintegrität)
- Protokoll (unterstützte TLS-Versionen, veraltete Protokolle deaktiviert)
- Funktionen (HSTS, OCSP Stapling, Perfect Forward Secrecy, CAA)
- Gültigkeit (verbleibende Zeit bis zum Ablauf)
Die meisten Bewertungsabfälle entstehen in der Kategorie Funktionen. Das Zertifikat funktioniert, die Kette ist in Ordnung, das Protokoll ist aktuell – aber HSTS ist nicht konfiguriert oder ein CAA-Eintrag ist nicht veröffentlicht. Das sind serverseitige und DNS-seitige Korrekturen, keine Zertifikatsprobleme.
Ihre Zertifikatsdetails lesen
Der SSL-Checker schlüsselt jedes Zertifikat in der Kette Feld für Feld auf.
Common Name – die primäre Domain, für die das Zertifikat ausgestellt wurde. Er muss mit der geprüften URL übereinstimmen, sonst lehnt der Browser die Verbindung ab.
Ausgestellt von – das ausstellende Intermediate-Zertifikat sowie die übergeordnete Certificate Authority. Bekannte Namen wie Sectigo, DigiCert, GeoTrust oder Google Trust Services werden automatisch als vertrauenswürdig eingestuft. Unbekannte Aussteller oder selbstsignierte Zertifikate lösen eine Warnung aus.
Gültig ab / Gültig bis – das Gültigkeitsfenster des Zertifikats. „Gültig ab“ ist wichtiger als oft angenommen: Wenn die Serveruhr falsch gestellt ist oder ein Zertifikat zu früh installiert wird, lehnen Browser es als noch nicht gültig ab.
Signaturalgorithmus – moderne Zertifikate verwenden SHA-256, SHA-384 oder ecdsa-with-SHA256. SHA-1 wurde vor Jahren als veraltet eingestuft, und jedes Zertifikat, das ihn noch verwendet, sollte neu ausgestellt werden.
Public Key – RSA mit 2048 Bit oder mehr ist Standard. ECC mit 256 Bit ist die moderne Alternative und erzeugt kleinere, schnellere Zertifikate.
SAN (Subject Alternative Name) – zusätzliche Hostnamen, die das Zertifikat abdeckt. Wildcards wie *.example.com decken alle Subdomains einer Ebene ab. Multi-Domain-Zertifikate listen hier jeden geschützten Hostnamen auf. Bei DV-, OV– oder EV-Zertifikaten legt die SAN-Liste genau fest, für welche Domains das Zertifikat gültig ist.
SSL-Zertifikat-Sicherheitsfunktionen erklärt
Über das Zertifikat selbst hinaus berichtet der SSL-Checker über ein Panel mit sechs Sicherheitsfunktionen.
OCSP Stapling – der Server ruft seinen eigenen Sperrstatus von der CA ab und fügt ihn beim TLS-Handshake auf Port 443 ein. „Not Supported“ erhöht die Latenz bei jeder Verbindung. In der Regel genügt eine einzeilige Konfigurationsänderung in Apache, Nginx oder IIS.
Perfect Forward Secrecy (PFS) – jede Sitzung verwendet einen einzigartigen Schlüssel, sodass ein zukünftiger Kompromiss des privaten Schlüssels vergangenen Datenverkehr nicht entschlüsseln kann. „Not Supported“ bedeutet, dass aufgezeichnete Sitzungen nachträglich entschlüsselt werden könnten. Aktivieren Sie dies, indem Sie ECDHE-Cipher-Suites bevorzugen.
Certificate Transparency (CT) – ausgestellte Zertifikate werden in öffentlichen CT-Logs protokolliert, sodass Domain-Inhaber fehlerhafte Ausstellungen erkennen können. „Not Supported“ bei einem öffentlichen Zertifikat ist ungewöhnlich.
HSTS (HTTP Strict Transport Security) – ein Server-Response-Header, der Browser anweist, einfache HTTP-Verbindungen abzulehnen. Ohne HSTS kann ein Angreifer einen Besucher von HTTPS auf HTTP herabstufen und den Datenverkehr abfangen. Fügen Sie einen Strict-Transport-Security-Header in der Webserver-Konfiguration hinzu.
Zertifikatssperrstatus – der Checker fragt OCSP und CRL ab, um zu bestätigen, dass das Zertifikat nicht gesperrt wurde. „Good“ = aktiv. „Revoked“ = Browser lehnen es ab, sofort neu ausstellen. „Unknown“ bei CRL ist häufig und kein Problem, wenn OCSP „Good“ zurückgibt.
DNS CAA-Eintrag – ein DNS-Eintrag, der auflistet, welche Certificate Authorities Zertifikate für die Domain ausstellen dürfen. Ohne einen solchen Eintrag könnte technisch gesehen jede CA ein Zertifikat ausstellen. Fügen Sie beim DNS-Anbieter einen CAA-Eintrag hinzu, der Ihre CAs auflistet.
Ergebnisse des TLS-Schwachstellen-Scans
Fünf bekannte TLS-Schwachstellen werden gescannt. Die meisten Server wurden vor Jahren gepatcht, daher bestätigt der SSL-Checker in der Regel Entwarnung.
Heartbleed (CVE-2014-0160) – ein OpenSSL-Speicherlesefehler, der private Schlüssel offenlegte. „Safe“ bedeutet, dass der Server einen gepatchten OpenSSL-Build verwendet.
POODLE (CVE-2014-3566) – ein Padding-Oracle-Angriff gegen SSLv3. „Safe“ bedeutet, dass SSLv3 deaktiviert ist.
BEAST (CVE-2011-3389) – ein TLS 1.0 Cipher-Block-Chaining-Fehler. „Safe“ bedeutet, dass TLS 1.0 deaktiviert ist oder der Server nicht anfällige Cipher Suites verwendet.
ROBOT (CVE-2017-13099) – Return Of Bleichenbacher’s Oracle Threat. Ein RSA-Padding-Fehler, der in vielen Herstellerimplementierungen wieder auftauchte. „Safe“ bedeutet, dass der Server keinen anfälligen Schlüsselaustausch offenlegt.
Ticketbleed (CVE-2016-9244) – F5 BIG-IP-spezifische Speicheroffenlegung über TLS-Session-Tickets. „Safe“ bedeutet, dass kein ungepatchtes F5-Gerät vorhanden ist.
Cipher Suites und Protokollunterstützung
Der SSL-Checker gruppiert unterstützte Cipher Suites unter TLS 1.3, TLS 1.2 und Schwach.
- TLS 1.3 verfügt über eine kleine Liste von von Grund auf starken Suites.
- Die Qualität der TLS 1.2-Cipher Suites variiert, weshalb jede Suite einzeln aufgeführt wird.
- Die Spalte Schwach kennzeichnet veraltete Protokolle oder Cipher Suites, die deaktiviert werden sollten: SSLv3, TLS 1.0, TLS 1.1, RC4, 3DES sowie alle NULL- oder EXPORT-Cipher.
Cipher-Suite-Namen folgen einer vorhersehbaren Struktur. In TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384:
- ECDHE ist der Schlüsselaustausch (bietet Perfect Forward Secrecy)
- ECDSA ist der Signaturalgorithmus
- AES_256_GCM ist der symmetrische Cipher
- SHA384 ist die Hash-Funktion
Sowohl 128-Bit– als auch 256-Bit-AES sind sicher.
Validierung der Zertifikatskette
Der Bericht zeigt die vollständige Zertifikatskette in drei Ebenen:
- Server-Zertifikat
- Intermediate-Zertifikat
- Root-Zertifikat
Jede Ebene wird von der darüberliegenden signiert, und die Kette muss bei einem Root-Zertifikat enden, dem der Browser bereits vertraut.
„Chain Complete“ bedeutet, dass Browser problemlos vom Server bis zum Root navigieren können.
„Incomplete“ bedeutet, dass ein oder mehrere Intermediate-Zertifikate fehlen, die der Server senden sollte, sodass Browser das Zertifikat nicht mit einem vertrauenswürdigen Root verknüpfen können und Besucher eine Sicherheitswarnung sehen.
Unvollständige Ketten sind eines der häufigsten SSL-Installationsprobleme, und der SSL-Checker kennzeichnet sie oben im Bericht. Die Lösung besteht fast immer darin, die Installation mit dem vollständigen Chain-Bundle der CA erneut durchzuführen. Die serverspezifischen Vorgehensweisen unterscheiden sich: Apache verwendet eine Chain-File-Direktive, während Nginx eine fullchain.pem erwartet. IIS verwaltet die Kettenwiederherstellung über den Zertifikat-Import-Assistenten.
Ablauf von SSL-Zertifikaten prüfen
Der SSL-Checker zeigt den Ablauf an zwei Stellen an: Die obere Zusammenfassung zeigt die verbleibenden Tage und das „Gültig bis“-Datum, und jedes Zertifikat in der Kette zeigt sein eigenes Gültigkeitsfenster.
Gemäß CA/Browser Forum Ballot SC-081v3 werden die Laufzeiten öffentlicher SSL/TLS-Zertifikate schrittweise verkürzt. Ab dem 15. März 2026 sank die maximale Gültigkeit von 398 Tagen auf 200 Tage. Ab dem 15. März 2027 sinkt sie auf 100 Tage und ab dem 15. März 2029 auf 47 Tage.
Bei einem 200-Tage-Zertifikat sind monatliche Prüfungen plus eine Erinnerung 30 Tage vor Ablauf ausreichend. Wenn 47-Tage-Zertifikate kommen, ist eine manuelle Erneuerung unpraktisch. Die Standardlösung ist ACME-basierte Automatisierung, die es dem Server ermöglicht, Zertifikate ohne manuellen Eingriff anzufordern und zu erneuern.
Browser-Kompatibilität – wann sie relevant ist
Der SSL-Checker testet das Zertifikat gegen 13 Browser- und Gerätekombinationen. Moderne Browser (Chrome 80+, Firefox 80+, Safari 14+, Edge 80+, Opera 70+, iOS 15+ Safari, Android 10+) sollten bei einem aktuellen Zertifikat immer „Supported“ anzeigen.
Ältere mobile Plattformen wie Android 5-7 und iOS 12 zeigen oft nur teilweise Unterstützung. Ob das relevant ist, hängt von der Zielgruppe ab. Ältere Desktop-Browser wie Internet Explorer 10 und 11 scheitern bei modernen Zertifikaten fast immer, da sie standardmäßig kein TLS 1.2 unterstützen. Ein Ergebnis von 9/13 mit allen modernen Browsern im grünen Bereich ist im Jahr 2026 normal.
Wann sollte ein SSL-Check durchgeführt werden?
Eine einmalige Prüfung nach der Installation reicht nicht aus. Führen Sie den SSL-Checker durch:
- Nach der Installation eines neuen Zertifikats
- 30 Tage vor Ablauf bei einem 200-Tage-Zyklus
- Nach jeder Erneuerung oder Neuausstellung
- Nach einer Server-Migration oder IP-Änderung
- Nach einem Wechsel der Certificate Authority
- Nach dem Wechsel zu einem Wildcard- oder Multi-Domain-Setup
- Nach der Aktivierung von HSTS, OCSP Stapling oder einer TLS-Konfigurationsänderung
Häufig gestellte Fragen
Monatlich ist ein angemessener Ausgangspunkt. Da 200-Tage-Zertifikate nun das Maximum darstellen, setzen Sie eine feste Erinnerung, um eine vollständige Überprüfung 30 Tage vor Ablauf durchzuführen. Führen Sie eine zusätzliche Überprüfung nach Erneuerungen durch, da Fehler bei der Chain-Bundle-Konfiguration das häufigste Problem nach der Erneuerung sind.
Link kopieren
Streben Sie nach einer A oder A+. Ein B funktioniert in jedem Browser, aber die Lücke deutet normalerweise auf behebbare Probleme hin. Die meisten Ratingabfälle lassen sich auf zwei Punkte zurückführen, die der SSL Checker im Panel für Sicherheitsfunktionen kennzeichnet: ein fehlender HSTS-Header oder ein nicht konfigurierter CAA-Datensatz. Keiner von beiden erfordert Änderungen am Zertifikat.
Link kopieren
Ihr Server sendet nicht alle Zwischenzertifikate, die Browser benötigen. Die schnelle Lösung: Apache verwendet SSLCertificateChainFile oder ein kombiniertes Bundle, Nginx erwartet eine fullchain.pem-Datei, und IIS erstellt die Kette über den Zertifikatimport-Assistenten neu.
Link kopieren
Nein, öffentliche Checker können nicht auf interne Hosts hinter Firewalls zugreifen. Führen Sie auf einem Computer im gleichen Netzwerk openssl s_client -connect host:443 -servername host aus, um eine gleichwertige Ausgabe zu erhalten. Das OpenSSL-Befehlszeilentool ist in den meisten Linux-Distributionen enthalten und ist für Windows verfügbar.
Link kopieren
Ja. Es liest das Zertifikat, das der Server präsentiert, von Sectigo, DigiCert, GeoTrust, RapidSSL, Thawte, GoGetSSL, Let’s Encrypt, Google Trust Services und anderen. SSL Dragons SSL-Zertifikat-Katalog deckt sechs dieser CAs nebeneinander ab.
Link kopieren
HSTS ist ein Server-Response-Header, nicht Teil des Zertifikats. Das Zertifikat kann vollkommen gültig sein, während HSTS nicht konfiguriert ist. Fügen Sie es in der Webserver-Konfiguration hinzu: Apache verwendet Header always set Strict-Transport-Security, Nginx verwendet add_header Strict-Transport-Security.
Link kopieren
