SSL-Zertifikat prüfen - So geht's richtig & sicher

Ein SSL-Zertifikat zu testen heißt mehr, als nur auf das Schloss im Browser zu schauen. Ich prüfe dabei immer, ob das Zertifikat zur Domain passt, ob die Zertifikatskette vollständig ist und ob der Server moderne TLS-Parameter sauber aushandelt. Genau darum geht es hier: ein praktischer, belastbarer Weg vom schnellen Erstcheck bis zur sauberen Bewertung der Konfiguration.

Was ich beim Zertifikat selbst prüfe

Technisch geht es bei der Alltagssprache oft um „SSL“, praktisch aber fast immer um TLS. Für die Prüfung zählt zuerst, ob das Zertifikat inhaltlich sauber ist: Gültigkeitszeitraum, Domainabdeckung, Aussteller und Zweck müssen stimmen. Seit Jahren verlasse ich mich dabei nicht mehr auf den Common Name allein, sondern auf das SAN-Feld, weil dort die tatsächlich akzeptierten Hostnamen stehen.

Die wichtigsten Punkte sind aus meiner Sicht schnell zusammengefasst:

• Gültigkeit: Das Zertifikat darf nicht abgelaufen sein und sollte noch genügend Restlaufzeit haben.
• Domainabdeckung: Die genaue Hostname-Kombination muss im SAN enthalten sein, bei Wildcards mit den richtigen Grenzen.
• Vertrauenskette: Serverzertifikat, Intermediate-CA und Root-CA müssen logisch zusammenpassen.
• Schlüsselpaar: Das Zertifikat muss zum hinterlegten Private Key gehören.
• Zweck: Für Webserver sollte die Nutzung als Serverzertifikat erkennbar sein.

Bei internen Systemen kann ein selbst signiertes oder intern ausgestelltes Zertifikat okay sein, aber nur dann, wenn die interne Trust-Chain bewusst verteilt und gepflegt wird. Für öffentliche Websites bewerte ich deutlich strenger, weil dort jeder Client ohne Vorwissen verbinden können muss. Als Nächstes geht es deshalb um die Werkzeuge, mit denen ich diese Basis schnell und sauber nachweise.

Mit welchen Werkzeugen ich die Prüfung am schnellsten eingrenze

Für einen ersten Check nehme ich nicht nur ein einziges Tool. Jedes Werkzeug zeigt eine andere Ebene: der Browser die Nutzerperspektive, OpenSSL die technische Handshake-Ebene und ein externer Scanner die Sicht von außen. Genau diese Kombination verhindert, dass ich mich von einem scheinbar grünen Häkchen täuschen lasse.

Bei öffentlichen Systemen nutze ich gern einen externen Testdienst wie SSL Labs, weil er den Server von außen bewertet und damit genau die Perspektive abbildet, die ein fremder Client später auch hat. Für schnelle lokale Diagnosen bleibt OpenSSL aber unverzichtbar. Damit ist die Werkzeugfrage geklärt, und jetzt kommt die Reihenfolge, die in der Praxis am zuverlässigsten funktioniert.

So teste ich ein Zertifikat Schritt für Schritt

Ich arbeite nie blind von oben nach unten, sondern beginne mit dem einfachsten Nachweis und gehe erst danach in die Tiefe. Das spart Zeit, weil sich viele Probleme schon in den ersten zwei Minuten eingrenzen lassen.

1. Ich prüfe den Hostnamen und die SNI-Ausgabe.

   Bei mehreren Domains auf einem Server ist SNI entscheidend. Ohne korrekte SNI-Angabe sieht man sonst leicht ein falsches Zertifikat.

   openssl s_client -connect example.de:443 -servername example.de -showcerts

2. Ich schaue auf Chain und Verifikationshinweis.

   OpenSSL s_client ist laut Dokumentation ein Testwerkzeug und kann die Verbindung auch bei Zertifikatsfehlern fortsetzen. Deshalb bewerte ich nicht nur die Ausgabe, sondern vor allem die Zeilen zur Verifikation und zur Kette.

3. Ich validiere die Kette separat.

   Mit openssl verify prüfe ich, ob das Zertifikat gegen einen Trust Store sauber aufgebaut werden kann.

   openssl verify -purpose sslserver -CAfile ca-bundle.pem server.crt

4. Ich teste das Verhalten eines echten Clients.

   Ein einfacher curl -Iv https://example.de-Aufruf zeigt mir schnell, ob die Verbindung aufgebaut wird und welches Zertifikat der Server tatsächlich ausliefert.

5. Ich vergleiche das Ergebnis mit einem externen Scan.

   Für produktive Webserver prüfe ich die Außenansicht noch einmal mit einem Scanner, damit ich Unterschiede zwischen interner und externer Wahrnehmung erkenne.

Wichtig ist dabei die Reihenfolge: Erst der Handshake, dann die Chain, dann der reale Client und erst danach der externe Vergleich. So vermeide ich Diagnosefehler wie „Zertifikat ist kaputt“, obwohl in Wahrheit nur der falsche Hostname angesprochen wurde. Im nächsten Schritt schauen wir auf die typischen Fehlermuster, die mir in solchen Checks am häufigsten begegnen.

Welche Fehlermuster ich am häufigsten sehe

Die meisten Probleme sind erstaunlich banal, aber genau deshalb werden sie oft zu spät erkannt. Ein Zertifikat kann technisch gültig sein und der Browser zeigt trotzdem Warnungen, weil die Seite daneben noch alte HTTP-Ressourcen lädt oder weil die Zertifikatskette unvollständig ausgeliefert wird.

Gerade gemischte Inhalte sind ein klassischer Fall: Das Zertifikat selbst ist in Ordnung, aber die Anwendung erzeugt trotzdem Sicherheitswarnungen, weil einzelne Ressourcen nicht per HTTPS geladen werden. Ein sauberer Zertifikatscheck endet deshalb nie am TLS-Handshake allein. Danach kommt die Frage, ob die Konfiguration auch aus Sicht moderner Clients wirklich rund ist.

Wann ich die Konfiguration als sauber bewerte

Eine Konfiguration ist für mich nicht dann gut, wenn sie irgendeinen Test knapp besteht, sondern wenn sie unter realen Bedingungen stabil und nachvollziehbar bleibt. Für öffentliche Websites setze ich heute mindestens TLS 1.2 voraus, besser TLS 1.3, und ich erwarte eine vollständige Kette ohne Warnungen. Alte Protokolle und unnötige Fallbacks sind aus meiner Sicht keine harmlose Altlast, sondern ein dauerhaftes Risiko.

Als grobe Zielmarke nutze ich diese Kriterien:

• Das Zertifikat ist gültig und für alle relevanten Hostnamen ausgestellt.
• Die Zertifikatskette wird ohne manuelle Eingriffe sauber aufgebaut.
• Der Server akzeptiert keine veralteten TLS-Versionen mehr.
• Die Seite liefert keine gemischten Inhalte, die den HTTPS-Status unterlaufen.
• Bei öffentlichen Webdiensten ist HSTS sinnvoll, weil es HTTPS erzwingt und Fehlumgehungen unterbindet.
• Wenn Zertifikatsstatus-Prüfungen wie OCSP sauber aktiv sind, ist das ein Plus für Verfügbarkeit und Vertrauensbild.

Für interne Anwendungen bewerte ich etwas anders: Dort kann ein internes Zertifikat völlig richtig sein, wenn die eigene CA kontrolliert verteilt wird und die Clients ihr vertrauen. Die Konfigurationsfrage ist also nie nur technisch, sondern auch betrieblich. Und genau dort liegt die eigentliche Daueraufgabe, nicht im einmaligen Prüfaufruf.

Was ich für den laufenden Betrieb mit einplane

Der sinnvollste Zertifikatstest ist wertlos, wenn er nur einmal im Quartal passiert und niemand die Laufzeit im Blick hat. In der Praxis plane ich deshalb immer ein kleines Betriebsmodell mit: Ablaufwarnungen, Verantwortlichkeiten, Automatisierung und einen festen Kontrollpunkt nach jedem Rollout. Bei Zertifikaten mit kurzen Laufzeiten, wie sie in vielen ACME-Setups üblich sind, ist das keine Kür, sondern Pflicht.

Praktisch hat sich für mich ein enger Warnkorridor bewährt: Ich lasse mich oft 30, 14 und 7 Tage vor Ablauf benachrichtigen, bei stark genutzten Systemen noch früher. Zusätzlich prüfe ich nach jedem Deployment erneut den Hostnamen, die Kette und das tatsächlich ausgelieferte Zertifikat, weil gerade Load Balancer und Multi-Node-Setups gern nebenbei verändert werden. Eine einfache Inventarliste mit Domain, Aussteller, Ablaufdatum, Schlüsseltyp und verantwortlichem Team spart hier mehr Ausfälle, als viele erwarten.

Am Ende ist ein sauberer TLS-Betrieb kein Einzeltest, sondern ein Prozess. Wer Zertifikate regelmäßig prüft, Erneuerungen automatisiert und die Auslieferung an jedem Endpunkt mit derselben Strenge kontrolliert, verhindert die meisten Störungen, bevor sie sichtbar werden.