Was ist ein SSL-Zertifikat?
Ein SSL/TLS-Zertifikat ist ein digitales Dokument, signiert von einer vertrauenswürdigen Zertifizierungsstelle (CA), das einen öffentlichen Schlüssel an einen oder mehrere Hostnamen bindet. Beim Verbindungsaufbau präsentiert der Server das Zertifikat im Rahmen des TLS-Handshakes, und der Client prüft die Signatur der CA, die Gültigkeitsdauer und dass einer der gelisteten Namen mit dem angeforderten Host übereinstimmt.
Trotz des historischen Namens nutzen moderne Zertifikate TLS (heute TLS 1.2 und 1.3) und nicht mehr das veraltete SSL. Das X.509-Zertifikatsformat und die PKI-Kette sind in **RFC 5280** definiert, das HTTPS-spezifische Verhalten in **RFC 2818**.
Warum sollten Sie Ihr SSL-Zertifikat prüfen?
1Plötzlichen Ablauf verhindern
Jeder Browser und moderne Mailclient bricht ab, sobald ein Zertifikat abläuft – überwachen Sie die Restlaufzeit proaktiv
2Hostname-Abdeckung bestätigen
Ein Zertifikat ist nur für die Hostnamen in seiner SAN-Liste gültig – prüfen Sie jede ausgelieferte Subdomain
3Nicht vertrauenswürdige Ketten erkennen
Selbstsignierte oder von unbekannten CAs ausgestellte Zertifikate lösen Browserwarnungen aus – decken Sie das vor Ihren Nutzern auf
4STARTTLS für E-Mails prüfen
Mailbox-Anbieter erwarten, dass MX-Endpunkte sauber auf TLS verhandeln – ein defektes Zertifikat verschlechtert die Zustellbarkeit unbemerkt
So funktioniert die SSL-Prüfung – Schritt für Schritt
Ein Client baut eine TLS-Verbindung zu Ihrer Domain auf und sendet ein ClientHello.
Ihr Server liefert seine Zertifikatskette: das Leaf-Zertifikat plus alle Zwischen-CA-Zertifikate.
Der Client folgt der Kette aufwärts bis zu einem vertrauenswürdigen Root-CA in seinem Truststore.
Er prüft jede Signatur, ob jedes Zertifikat innerhalb seiner Gültigkeit liegt und ob keines widerrufen wurde.
Zum Schluss prüft er, dass die SAN-Liste des Leaf-Zertifikats den Hostnamen enthält, der angefordert wurde.
Bestehen alle Schritte, wird der Handshake abgeschlossen und der Sitzungsschlüssel ausgetauscht.
Zertifikatsfelder auf einen Blick
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
| openssl x509 -noout -textWichtige Zertifikatsfelder
Issuer— Zertifizierungsstelle, die das Zertifikat signiert hatSubject CN— alter primärer HostnameSAN— moderne Liste gültiger HostnamenNot Before / After— GültigkeitsfensterKey Usage— erlaubte Operationen (Server-Auth usw.)Häufige SSL-Fehler und Lösungen
Abgelaufenes Zertifikat
Sofort erneuern und Monitoring einrichten – die meisten Teams alarmieren bei 30 verbleibenden Tagen
Hostname stimmt nicht überein
Der getestete Hostname fehlt im SAN – Zertifikat mit dem fehlenden Namen oder einem korrekten Wildcard neu ausstellen
Selbstsigniertes Zertifikat
Browser lehnen das ab – wechseln Sie zu einem kostenlosen Let's-Encrypt-Zertifikat oder einem verwalteten Zertifikat Ihres CDNs
Unvollständige Kette
Fehlen Zwischenzertifikate, können einige Clients die Kette nicht prüfen – bündeln Sie sie mit dem Leaf in der Serverkonfiguration
Häufig gestellte Fragen
Ein SSL/TLS-Zertifikatschecker bestätigt, dass eine Domain ein gültiges Zertifikat einer vertrauenswürdigen Zertifizierungsstelle ausliefert, dass Subject und Subject Alternative Names den getesteten Hostnamen abdecken, dass das Zertifikat innerhalb seines Gültigkeitsfensters liegt und dass es nicht selbstsigniert ist. Diese Prüfungen beweisen zusammen, dass ein Browser oder Mailclient der Verbindung vertraut.
Sobald ein Zertifikat abläuft, zeigt jeder Browser eine Sicherheitswarnung an, und die meisten modernen Mailclients verweigern STARTTLS. Ein Ablauf reißt sowohl Webverkehr als auch authentifiziertes Mail-Submission mit sich. Die Restlaufzeit zu überwachen gibt Ihnen einen Puffer zur Erneuerung – die meisten Teams alarmieren unter 30 Tagen.
Subject CN (Common Name) ist das alte Einzel-Hostnamen-Feld auf einem Zertifikat. Subject Alternative Names (SAN) ist eine moderne Liste aller Hostnamen, für die das Zertifikat gültig ist – inklusive Wildcard-Einträge. Browser und die meisten Mailclients ignorieren den CN inzwischen vollständig und validieren gegen die SAN-Liste, jeder fehlende Hostname schlägt die TLS-Prüfung fehl.
Selbstsignierte Zertifikate sind für jeden öffentlichen Dienst unsicher. Sie verschlüsseln zwar die Verbindung, beweisen aber keine Identität, daher lehnen Browser, mobile Geräte und Unternehmens-Mailclients sie ab. Sie sind nur in Entwicklungs- oder internen Diensten akzeptabel, in denen Sie jeden Client kontrollieren, oder als Zwischenschritt vor der Ausstellung eines vertrauenswürdigen Zertifikats.
Eine Hostname-Diskrepanz tritt auf, wenn die SAN-Liste des Zertifikats den getesteten Namen nicht enthält. Häufige Ursachen sind das Testen einer www-Subdomain gegen ein Nur-Apex-Zertifikat, fehlende Wildcards für Sub-Subdomains oder das versehentliche Ausliefern des falschen virtuellen Hosts auf einer geteilten IP. Stellen Sie das Zertifikat mit korrekten SAN-Einträgen neu aus.
Ja, indirekt. Mailbox-Anbieter erwarten, dass MX-, SMTP-Submission- und Tracking-Endpunkte erfolgreich TLS verhandeln. Ein defektes oder abgelaufenes Zertifikat erzwingt einen Downgrade auf Klartext oder einen Zustellfehler, was die Reputation langfristig senkt. Alle Mail-Domains mit grünem Schloss zu halten ist Teil einer gesunden Authentifizierungsstrategie.