SSL-Zertifikat-Prüfer

Was ist ein SSL-Zertifikat-Checker?

Ein SSL-Zertifikat-Checker ueberprueft das SSL/TLS-Zertifikat einer Website: Gueltigkeit, Ablaufdatum, Zertifikatskette, Verschluesselungsstaerke und moegliche Konfigurationsfehler.

SSL/TLS (Secure Sockets Layer / Transport Layer Security) verschluesselt die Kommunikation zwischen Browser und Server. HTTPS ist heute Standard — Google bevorzugt HTTPS-Seiten im Ranking und Browser warnen bei HTTP.

Warum HTTPS und TLS wichtig sind

TLS (Transport Layer Security) bietet drei grundlegende Garantien für jede HTTPS-Verbindung. Erstens Verschlüsselung: Alle Daten, die zwischen Browser und Server ausgetauscht werden, sind verschlüsselt, sodass jemand, der den Datenverkehr abfängt – etwa in einem öffentlichen WLAN –, nur unleserliche Bytes sieht. Zweitens Integrität: TLS verwendet Message Authentication Codes (MACs), um Manipulationen während der Übertragung zu erkennen und sicherzustellen, dass weder Anfrage noch Antwort verändert wurden. Drittens Authentifizierung: Das Zertifikat ermöglicht es dem Browser zu überprüfen, dass er mit dem echten Server kommuniziert und nicht mit einem Angreifer, der einen Man-in-the-Middle-Angriff durchführt.

Über die Sicherheit hinaus ist HTTPS ein Rankingfaktor für die Google-Suche und Voraussetzung für moderne Browser-Funktionen wie Service Workers, Geolokalisierung und Kamerazugriff. Browser wie Chrome und Firefox kennzeichnen HTTP-Seiten als „Nicht sicher“, was das Nutzervertrauen untergräbt und die Absprungrate erhöht. Websites ohne gültiges Zertifikat können zudem auf Threat-Intelligence-Blocklisten auftauchen, die von Unternehmens-Firewalls genutzt werden, und so ganze Nutzergruppen ausschließen.

Was der Prüfer im Detail anzeigt

Eine vollständige SSL/TLS-Zertifikatsprüfung geht über ein einfaches Bestanden/Nicht-Bestanden hinaus. Das bedeuten die einzelnen Felder:

• Gültigkeitszeitraum und Ablauf — Das Zertifikat enthält einen notBefore- und notAfter-Zeitstempel. Der Prüfer bestätigt, dass das aktuelle Datum innerhalb dieses Zeitraums liegt, und zeigt an, wie viele Tage bis zum Ablauf verbleiben. Bei einem Wert unter 30 Tagen sollte sofort eine Verlängerung eingeleitet werden.
• Aussteller und Zertifizierungsstelle (CA) — Das Ausstellerfeld identifiziert die CA, die das Zertifikat signiert hat, beispielsweise „Let’s Encrypt Authority X3“, „DigiCert TLS RSA SHA256 2020 CA1“ oder „Sectigo RSA Domain Validation CA“. Anhand des Ausstellers lässt sich prüfen, ob eine Website eine vertrauenswürdige CA verwendet und keine obskure oder private.
• Subject und Subject Alternative Names (SANs) — Der Subject-CN (Common Name) war historisch der Hostname, für den das Zertifikat ausgestellt wurde. Moderne Zertifikate stützen sich auf SANs, eine Liste aller Domains und Subdomains, die das Zertifikat schützt. Ein einziges Zertifikat kann sowohl example.com als auch www.example.com oder Dutzende von Subdomains abdecken. Eine Abweichung zwischen dem Hostnamen, mit dem Sie sich verbinden, und der SAN-Liste führt zu einem Namens-Konfliktfehler.
• Vertrauenskette — Browser vertrauen einer kleinen Gruppe von Root-CAs, die im Betriebssystem vorinstalliert sind. Ihr Serverzertifikat wird fast nie direkt von einer Root-CA signiert; stattdessen wird es von einer Zwischen-CA signiert, die ihrerseits von der Root signiert ist. Der Server muss die vollständige Kette übermitteln – Blattzertifikat plus alle Zwischen-CA-Zertifikate –, damit Browser den Vertrauenspfad aufbauen können. Ein fehlendes Zwischenzertifikat ist eine der häufigsten Ursachen für Zertifikatsfehler auf Mobilgeräten.
• Schlüsseltyp und Signaturalgorithmus — Der Prüfer zeigt den Algorithmus des öffentlichen Schlüssels an (RSA 2048-Bit oder RSA 4096-Bit sind am gebräuchlichsten; ECDSA P-256 gewinnt aus Leistungsgründen an Beliebtheit) sowie den Signaturalgorithmus der CA (z. B. SHA-256 mit RSA). SHA-1-Signaturen sind seit 2017 veraltet und führen zu Browser-Fehlern; SHA-256 ist der aktuelle Standard.

Was wird ueberprueft?

• Ablaufdatum — abgelaufene Zertifikate erzeugen Browserwarnungen. Let's Encrypt Zertifikate laufen alle 90 Tage ab.
• Zertifikatskette — das Zertifikat muss zu einer vertrauenswuerdigen Zertifizierungsstelle (CA) zurueckverfolgbar sein.
• Domainname — der im Zertifikat angegebene Name muss mit der aufgerufenen Domain uebereinstimmen. Wildcard-Zertifikate: *.example.com.
• Verschluesselungstaerke — TLS 1.2 oder 1.3, RSA 2048+ Bit oder ECDSA 256+ Bit. Aeltere Protokolle (SSL 3.0, TLS 1.0/1.1) sind unsicher.
• HSTS-Header — HTTP Strict Transport Security erzwingt HTTPS und schuetzt vor Downgrade-Angriffen.

So verwenden Sie dieses Tool

Geben Sie einen Domainnamen ein (z.B. example.com). Das Tool verbindet sich mit dem Server, prueft das SSL-Zertifikat und zeigt einen detaillierten Bericht mit Warnungen und Empfehlungen.

Zertifikatstypen

DV (Domain Validation) — bestaetigt nur die Domain-Kontrolle. Schnell und kostenlos (Let's Encrypt). OV (Organization Validation) — bestaetigt die Organisation. EV (Extended Validation) — strengste Pruefung, zeigt den Firmennamen. Fuer Vertrauen: OV oder EV fuer Shops und Banken.

Häufige Zertifikatsfehler und ihre Bedeutung

Browser und Server-TLS-Stacks sind streng. Folgende Fehler treten am häufigsten auf:

• Zertifikat abgelaufen (NET::ERR_CERT_DATE_INVALID) — Das aktuelle Datum liegt nach dem notAfter-Zeitstempel. Die Verbindung wird von allen gängigen Browsern standardmäßig blockiert. Lösung: Zertifikat sofort erneuern. Bei Verwendung von Let's Encrypt: certbot renew ausführen oder prüfen, warum der automatisierte Erneuerungs-Cronjob oder der systemd-Timer fehlgeschlagen ist.
• Hostname-Konflikt (NET::ERR_CERT_COMMON_NAME_INVALID) — Die Domain in der Adresszeile erscheint nicht in der SAN-Liste des Zertifikats. Häufige Ursachen: Das Zertifikat wurde für www.example.com ausgestellt, die Website wird aber auch über example.com (ohne www) ausgeliefert, oder ein altes Zertifikat verblieb nach einer Domain-Änderung auf dem Server. Lösung: Zertifikat neu ausstellen und alle erforderlichen Hostnamen aufnehmen.
• Selbstsigniertes Zertifikat — Das Zertifikat wurde mit demselben Schlüssel signiert, den es schützt, statt von einer vertrauenswürdigen CA. Browser können die Identität nicht verifizieren und zeigen eine Warnung „Nicht vertrauenswürdiges Zertifikat“ an. Selbstsignierte Zertifikate sind in internen Netzwerken und Entwicklungsumgebungen akzeptabel, dürfen aber niemals auf öffentlichen Produktionsseiten eingesetzt werden.
• Nicht vertrauenswürdige Root-CA — Das Zertifikat wurde von einer CA ausgestellt, die nicht im Vertrauensspeicher des Browsers oder Betriebssystems enthalten ist. Dies kann bei privaten CAs, einigen nationalen CAs, die aus Vertrauensspeichern entfernt wurden, oder bei neu eingerichteten CAs auftreten, deren Root-Zertifikat noch nicht weit verbreitet ist. Lösung: Wechsel zu einer bekannten öffentlichen CA.
• Unvollständige Zertifikatskette — Der Server sendet nur das Blattzertifikat ohne die erforderlichen Zwischen-CA-Zertifikate. Der Browser kann den Vertrauenspfad zu einer Root-CA nicht aufbauen. Desktop-Browser können fehlende Zwischenzertifikate manchmal über AIA (Authority Information Access) nachladen, mobile Browser und viele API-Clients jedoch nicht. Lösung: Webserver (nginx, Apache, Caddy) so konfigurieren, dass er das vollständige Zertifikats-Bundle ausliefert.

Zertifikatserneuerung und Automatisierung

Let's Encrypt, die kostenlose, automatisierte und offene CA der Internet Security Research Group (ISRG), hat das Zertifikatsmanagement grundlegend verändert. Let's Encrypt-Zertifikate haben by Design eine Gültigkeitsdauer von 90 Tagen – die kurze Laufzeit begrenzt den Schaden bei einem kompromittierten privaten Schlüssel und fördert die Automatisierung. Das ACME-Protokoll (Automated Certificate Management Environment, RFC 8555) ermöglicht es einem Client wie Certbot, acme.sh oder einem Cloud-Loadbalancer, automatisch die Domain-Kontrolle nachzuweisen (über HTTP-01- oder DNS-01-Challenges) und ein frisches Zertifikat ohne menschlichen Eingriff abzurufen. Bei korrekter Konfiguration erneuern ACME-Clients Zertifikate etwa 30 Tage vor Ablauf, sodass manuelle Verlängerungen überflüssig werden.

Auch bei Automatisierung ist Monitoring unverzichtbar. Automatisierung kann lautlos scheitern – durch Firewall-Änderungen, DNS-Fehlkonfigurationen, erschöpfte Rate-Limits oder ein abgelaufenes Dienstkonto. Best Practice ist die Einrichtung eines externen Ablauf-Monitors – ein Cron-Job, ein Drittanbieter-Dienst oder ein Uptime-Tool –, der Sie warnt, wenn die verbleibende Gültigkeitsdauer eines Zertifikats unter 21 Tage fällt. Eine fehlgeschlagene Erneuerung zu erkennen, solange noch drei Wochen Puffer verbleiben, ist weit weniger stressig, als von Ihren Nutzern auf ein abgelaufenes Zertifikat hingewiesen zu werden.

Häufige Fehler, die vermieden werden sollten

• Auf Kalendererinnerungen statt Automatisierung setzen — Manuell verwaltete Verlängerungen scheitern, wenn der zuständige Ingenieur im Urlaub ist oder die Stelle wechselt. Verwenden Sie einen ACME-Client mit systemd-Timer oder Cron-Job und überprüfen Sie, ob der Job tatsächlich läuft.
• Eine unvollständige Zertifikatskette deployen — Nur das Blattzertifikat auf den Server zu kopieren und Zwischen-CA-Zertifikate wegzulassen führt zu Fehlern auf Mobilgeräten und Nicht-Browser-Clients, auch wenn Desktop-Chrome unauffällig erscheint (er lädt das fehlende Zwischenzertifikat stillschweigend nach).
• Subdomains vergessen — Ein Zertifikat für example.com, aber nicht für www.example.com auszustellen (oder umgekehrt) erzeugt Hostname-Konfliktfehler. Verwenden Sie ein Wildcard-Zertifikat (*.example.com) oder ein SAN-Zertifikat, das alle erforderlichen Hostnamen auflistet.
• Ablaufwarnungen ignorieren — Viele ACME-Clients senden eine E-Mail-Warnung, wenn ein Zertifikat bald abläuft und die automatische Erneuerung nicht ausgeführt wurde. Diese E-Mails gehen in einem vollen Posteingang leicht unter. Richten Sie einen dedizierten Benachrichtigungskanal (Slack, PagerDuty o. Ä.) für Zertifikatsablauf-Meldungen ein.

Haeufig gestellte Fragen

Was passiert, wenn mein SSL-Zertifikat ablaeuft?

Browser zeigen eine ganzseitige Warnung ('Verbindung ist nicht privat'), die die meisten Besucher abschreckt. Google kann die Seite aus dem Index entfernen. Richten Sie automatische Erneuerung ein (certbot fuer Let's Encrypt).

Ist Let's Encrypt sicher genug?

Ja. Let's Encrypt bietet die gleiche Verschluesselungsstaerke wie kostenpflichtige Zertifikate. Es ist DV — bestaetigt nur die Domain-Kontrolle. Fuer zusaetzliche Vertrauenssignale (Firmenname im Zertifikat) benoetigen Sie OV oder EV.

Was ist eine Zertifikatskette und warum ist sie wichtig?

Eine Zertifikatskette (oder Vertrauenskette) ist die Abfolge von Zertifikaten vom Blattzertifikat Ihres Servers bis zu einer vertrauenswürdigen Root-CA. Browser vertrauen nur einer kleinen Anzahl von Root-CAs, aber diese Roots signieren Zwischen-CAs, die wiederum Serverzertifikate signieren. Ihr Webserver muss das Blattzertifikat zusammen mit allen Zwischenzertifikaten im TLS-Handshake übermitteln. Fehlt ein Zwischenzertifikat, können Clients, die es nicht gecacht haben, das Zertifikat nicht verifizieren und zeigen einen Fehler an – obwohl das Zertifikat selbst einwandfrei gültig ist.

Wie lange sind SSL/TLS-Zertifikate gültig?

Browser-vertrauenswürdige öffentliche Zertifikate haben eine maximale Gültigkeitsdauer von 398 Tagen (rund 13 Monate), wie vom CA/Browser Forum seit September 2020 vorgeschrieben. Let's Encrypt stellt Zertifikate mit 90 Tagen Gültigkeit aus, um Automatisierung zu fördern. Zertifikate interner oder privater CAs können längere Laufzeiten haben, Best Practice ist jedoch, sie unter zwei Jahren zu halten. Kürzere Laufzeiten verringern das Risikofenster, falls ein privater Schlüssel kompromittiert wird.