Eine ausgelieferte TLS-Zertifikatskette und ihr Ablaufdatum von der Kommandozeile aus mit openssl prüfen

Ziel

Für einen Hostnamen drei Fragen beantworten, die ein Browser stillschweigend beantwortet: welche Zertifikate der Server sendet, ob sie eine Kette bilden, die ein Client verifizieren kann, und wann jedes davon abläuft. Dies ist die einmalige Diagnose; geplante Alarmierung ist ein separater Artikel.

Voraussetzungen

Ein openssl-Binary, Netzwerkzugriff auf den Host und die genauen Hostnamen, die Clients verwenden (Apex, www, API-Hosts), da der Server pro Name ein anderes Zertifikat wählen kann.

Schritte

1. Abrufen, was der Server sendet, mit explizit gesetztem SNI: openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null > sent.txt. Das Handbuch besagt, dass -showcerts die Serverzertifikatsliste so anzeigt, wie sie gesendet wurde, in der gesendeten Reihenfolge, und dass diese Liste keine verifizierte Kette ist. Es besagt ausserdem, dass ohne -servername das SNI nur dann aus dem -connect-Namen gefüllt wird, wenn dieser wie ein DNS-Name aussieht, weshalb es beim Verbinden zu einer IP-Adresse angegeben werden muss.
2. Das Verifikationsergebnis lesen, das s_client nach dem Handshake ausgibt; eine lokal verifizierende Kette braucht dennoch Schritt 4, da der lokale Trust Store ein Zwischenzertifikat enthalten kann, das Clients fehlt.
3. sent.txt in eine PEM-Datei pro Zertifikat aufteilen und jede prüfen: openssl x509 -in cert1.pem -noout -subject -issuer -enddate -ext subjectAltName. Laut Handbuch gibt -enddate das notAfter-Datum aus und -ext benannte Erweiterungen wie subjectAltName. Das erste Zertifikat sollte das Blatt sein, dessen SANs den Hostnamen enthalten; jedes folgende Zertifikat sollte der Aussteller des vorherigen sein.
4. Die Kette unabhängig von der Behauptung des Servers neu aufbauen: openssl verify -show_chain -untrusted intermediates.pem leaf.pem. Das Handbuch beschreibt -untrusted als eine Datei mit nicht vertrauenswürdigen Zertifikaten, die für den Kettenaufbau verwendet wird, und -show_chain als Anzeige der aufgebauten Kette, wobei nicht vertrauenswürdige Mitglieder markiert werden. Gegen den System-Trust-Store ausführen und, falls nötig, gegen eine bestimmte -CAfile.
5. Schritt 1 mit -4 und erneut mit -6 wiederholen; das Handbuch dokumentiert diese als reine IPv4- bzw. IPv6-Verbindungen. Ein Load Balancer kann pro Adressfamilie ein anderes Zertifikat ausliefern.
6. Für jeden Hostnamen und jeden Port, der TLS terminiert, wiederholen.
7. Hostname, Adressfamilie, notAfter des Blatts, frühestes notAfter eines Zwischenzertifikats und Verifikationsergebnis in einer Tabelle festhalten.

Erwartetes Ergebnis

Eine kurze Tabelle pro Hostname, die zeigt, dass die gesendete Kette vollständig und geordnet ist, dass die Verifikation gelingt, ohne dass der lokale Trust Store ein fehlendes Zwischenzertifikat kaschiert, und das früheste Ablaufdatum in der Kette.

Grenzen und Prüfbasis

Ein fehlendes Zwischenzertifikat kann auf einer Maschine bestehen, die es zwischengespeichert hat, und bei einem frischen Client scheitern; Schritt 4 mit einem minimalen Trust Store ist der ehrliche Test. Die Befehle folgen den zitierten Handbüchern; die Verfügbarkeit der Optionen variiert je nach OpenSSL-Version. Es werden keine Feldergebnisse behauptet.