2.10 OpenSSL – TLS-Verbindungen, Zertifikate und Zertifikatsketten prüfen

Ausführliche Buildinformationen

[RO] openssl version -a

Die Ausgabe kann unter anderem enthalten:

• OpenSSL- oder LibreSSL-Version;
• Erstellungsdatum;
• Zielplattform;
• Konfigurationsverzeichnis;
• Provider- und Modulpfade;
• Compileroptionen;
• CPU-Funktionen.

Betriebssystemspezifische Hinweise

OpenSSL und LibreSSL sind nicht vollständig optionskompatibel. Vor der Übernahme eines Befehls muss deshalb geprüft werden:

openssl version
openssl s_client -help

[TEST][SENS] openssl s_client -connect example.com:443

Der Befehl baut eine TCP-Verbindung zu Port 443 auf und startet anschließend einen TLS-Handshake.

Mit ausdrücklich gesetztem SNI

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com

-servername setzt die TLS-Erweiterung Server Name Indication.

Kompakte Ausgabe, sofern von der installierten Version unterstützt

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -brief

Verbindung beenden

Nach dem TLS-Handshake wartet s_client häufig auf weitere Eingaben. Die Sitzung kann normalerweise mit folgender Tastenkombination beendet werden:

[Strg] + [C]

Neuere OpenSSL-Versionen unterstützen einen nicht interaktiven Modus:

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -no-interactive

Vor Verwendung muss geprüft werden:

[RO] openssl s_client -help

Wichtige Ausgabeinformationen

• Ziel-IP und Zielport;
• Serverzertifikat;
• Zertifikatskette;
• TLS-Version;
• Cipher Suite;
• Schlüsselaustausch;
• Signaturalgorithmus;
• ALPN-Ergebnis;
• Zertifikatsprüfergebnis;
• Sitzungsinformationen.

Mehrere HTTPS-Dienste können dieselbe IP-Adresse und denselben Port verwenden:

192.0.2.20:443
├── wiki.example.com
├── mail.example.com
└── api.example.com

Der Client teilt dem Server während des TLS-Handshakes mit, welchen Hostnamen er erreichen möchte. Das geschieht über SNI.

Wiki prüfen

[TEST][SENS] openssl s_client -connect 192.0.2.20:443 -servername wiki.example.com

API prüfen

[TEST][SENS] openssl s_client -connect 192.0.2.20:443 -servername api.example.com

Der Server kann abhängig vom SNI-Namen unterschiedliche Zertifikate zurückgeben.

Ohne SNI

[TEST][SENS] openssl s_client -connect 192.0.2.20:443 -noservername

Mögliche Folgen:

• Standardzertifikat des Reverse Proxys;
• Zertifikat eines anderen virtuellen Hosts;
• TLS-Abbruch;
• falsche Anwendung;
• irreführender Zertifikatsnamensfehler.

Ein Test gegen eine IP-Adresse ohne passenden SNI-Namen bildet den Zugriff eines normalen Browsers auf einen DNS-Namen nicht zuverlässig nach.

Angenommen:

Hostname: wiki.example.com
Test-IP: 192.0.2.20
Port: 443

Direkter TLS-Test gegen diese IP mit richtigem SNI

[TEST][SENS] openssl s_client -connect 192.0.2.20:443 -servername wiki.example.com

Dadurch wird:

• die DNS-Auflösung für die Verbindung umgangen;
• die Verbindung direkt zu 192.0.2.20 aufgebaut;
• SNI auf wiki.example.com gesetzt.

Für eine vollständige Hostnamenprüfung sollte zusätzlich verwendet werden:

[TEST][SENS] openssl s_client -connect 192.0.2.20:443 -servername wiki.example.com -verify_hostname wiki.example.com -verify_return_error

Vergleich mit curl

[TEST][SENS] curl --resolve wiki.example.com:443:192.0.2.20 https://wiki.example.com/

OpenSSL untersucht hauptsächlich TLS und Zertifikate. curl führt zusätzlich eine HTTP-Anfrage aus.

Ein erfolgreicher TLS-Handshake beweist zunächst:

• TCP-Verbindung wurde hergestellt;
• Client und Server fanden eine gemeinsame TLS-Version;
• Client und Server fanden geeignete kryptografische Parameter;
• der Server konnte ein Zertifikat oder anderes benötigtes Material bereitstellen;
• verschlüsselte Kommunikation konnte grundsätzlich beginnen.

Er beweist nicht automatisch:

• dass der Zertifikatsname richtig ist;
• dass die Zertifikatskette vertrauenswürdig ist;
• dass das Zertifikat nicht abgelaufen ist;
• dass die Anwendung funktioniert;
• dass HTTP einen erfolgreichen Statuscode liefert;
• dass eine Benutzeranmeldung möglich ist;
• dass eine Sperrprüfung erfolgreich war.

Diagnoseebenen

DNS
  ↓
TCP
  ↓
TLS-Handshake
  ↓
Zertifikatsprüfung
  ↓
HTTP oder anderes Anwendungsprotokoll
  ↓
Anwendung

Für HTTPS sollte nach dem OpenSSL-Test zusätzlich eine HTTP-Prüfung erfolgen:

[TEST][SENS] curl -v https://wiki.example.com/

openssl s_client ist ein Diagnosewerkzeug. Standardmäßig kann es nach Zertifikatsprüffehlern fortfahren, damit weitere Probleme sichtbar werden.

Eine Ausgabe wie:

verify error:num=20:unable to get local issuer certificate

bedeutet deshalb nicht zwingend, dass der TLS-Handshake sofort abgebrochen wird.

Bei Zertifikatsfehlern wirklich abbrechen

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -verify_return_error

Zusätzlich Hostnamen prüfen

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -verify_return_error

Erwartetes positives Ergebnis

Verification: OK

oder in der ausführlichen Ausgabe:

Verify return code: 0 (ok)

Wichtig

TLS-Handshake abgeschlossen
≠
Zertifikat erfolgreich validiert

Für eine belastbare Prüfung müssen mindestens berücksichtigt werden:

• -verify_return_error;
• der erwartete Hostname;
• der richtige Vertrauensspeicher;
• die vollständige Zertifikatskette.

DNS-Hostname prüfen

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -verify_return_error

Verbindung gegen IP, aber DNS-Namen prüfen

[TEST][SENS] openssl s_client -connect 192.0.2.20:443 -servername wiki.example.com -verify_hostname wiki.example.com -verify_return_error

IP-Adresse als Zertifikatsidentität prüfen

[TEST][SENS] openssl s_client -connect 192.0.2.20:443 -verify_ip 192.0.2.20 -verify_return_error

Ein Zertifikat muss die IP-Adresse dafür als IP-Eintrag im Subject Alternative Name enthalten. Ein DNS-Name oder ein Common Name mit einer IP-ähnlichen Zeichenfolge ist dafür nicht automatisch ausreichend.

Zu unterscheiden

Diese Werte können bei gezielten Tests unterschiedlich sein.

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -showcerts

-showcerts zeigt die Zertifikate so an, wie der Server sie übermittelt hat.

Typische Reihenfolge:

1. Server-/Leaf-Zertifikat
2. Zwischenzertifikat
3. weiteres Zwischenzertifikat

Ein Root-Zertifikat wird von einem TLS-Server normalerweise nicht mitgesendet, weil es bereits im Vertrauensspeicher des Clients vorhanden sein soll.

Wichtiger Hinweis

Die Ausgabe von -showcerts ist:

• die vom Server gesendete Zertifikatsliste;
• nicht automatisch eine erfolgreich validierte Kette;
• nicht zwingend vollständig;
• nicht zwingend in einer brauchbaren Vertrauenskette angeordnet;
• kein Beweis, dass alle Zertifikate vertrauenswürdig sind.

Typischer Fehler

Server sendet nur Leaf-Zertifikat
→ Client kann Aussteller möglicherweise nicht finden
→ unable to get local issuer certificate

Unter Linux und macOS kann das erste vom Server ausgegebene Zertifikat an openssl x509 weitergegeben werden:

[TEST][FILE][SENS] openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -outform PEM > server-cert.pem

Anschließend prüfen:

[RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -subject -issuer -dates

Wichtig

Diese Pipeline übernimmt normalerweise das erste PEM-Zertifikat aus der Ausgabe und damit üblicherweise das Leaf-Zertifikat. Sie speichert nicht automatisch die vollständige Zertifikatskette.

Für die vollständige Kette sollte die Ausgabe von -showcerts kontrolliert und jedes Zertifikat eindeutig getrennt gespeichert werden.

Unter Windows

Shell-Pipelines und Umleitungen unterscheiden sich zwischen:

• PowerShell;
• Eingabeaufforderung;
• Git Bash;
• WSL.

Daher sollte unter Windows zunächst die Ausgabe kontrolliert in eine Datei geschrieben und das gewünschte PEM-Zertifikat anschließend eindeutig extrahiert werden. Binärdaten und private Schlüssel dürfen nicht unkontrolliert durch Textkonvertierungen einer Shell verändert werden.

[RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -text

Kompakte Kerninformationen

[RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -subject -issuer -serial -dates

SHA-256-Fingerabdruck

[RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -fingerprint -sha256

Public-Key-Information

[RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -pubkey

Wichtige Zertifikatsfelder

[RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -ext subjectAltName

Beispiel:

X509v3 Subject Alternative Name:
    DNS:example.com, DNS:www.example.com, DNS:api.example.com

Weitere Erweiterungen

[RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -ext keyUsage

[RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -ext extendedKeyUsage

[RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -ext basicConstraints

[RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -ext authorityInfoAccess

Wichtig

Moderne TLS-Clients prüfen die Identität hauptsächlich anhand von Subject Alternative Name. Der Common Name allein sollte nicht als verlässlicher Ersatz für fehlende SAN-Einträge betrachtet werden.

Gültigkeitszeitraum anzeigen

[RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -dates

Ausgabe:

notBefore=...
notAfter=...

Nur Ablaufdatum

[RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -enddate

Prüfen, ob das Zertifikat mindestens noch 30 Tage gültig ist

[RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -checkend 2592000

Berechnung:

30 Tage × 24 Stunden × 60 Minuten × 60 Sekunden
= 2.592.000 Sekunden

Exitcode auswerten

Linux und macOS:

openssl x509 -in server-cert.pem -noout -checkend 2592000
echo $?

PowerShell:

openssl.exe x509 -in server-cert.pem -noout -checkend 2592000
$LASTEXITCODE

Zusätzlich muss die lokale Systemzeit korrekt sein. Eine falsche Uhr kann gültige Zertifikate als noch nicht gültig oder abgelaufen erscheinen lassen.

Angenommene Dateien:

server-cert.pem
intermediate-ca.pem
root-ca.pem

Kette prüfen

[RO][FILE][SENS] openssl verify -CAfile root-ca.pem -untrusted intermediate-ca.pem server-cert.pem

Erwartetes Ergebnis:

server-cert.pem: OK

Zusätzlich Hostnamen prüfen

[RO][FILE][SENS] openssl verify -CAfile root-ca.pem -untrusted intermediate-ca.pem -verify_hostname wiki.example.com server-cert.pem

Für TLS-Serverzweck prüfen

[RO][FILE][SENS] openssl verify -CAfile root-ca.pem -untrusted intermediate-ca.pem -purpose sslserver server-cert.pem

Bedeutung

Das Zwischenzertifikat wird mit -untrusted zur Kettenbildung bereitgestellt. Dadurch wird es nicht automatisch selbst zum Vertrauensanker.

Prüfreihenfolge

1. Leaf-Zertifikat untersuchen.
2. Issuer des Leaf-Zertifikats bestimmen.
3. Passendes Zwischenzertifikat prüfen.
4. Issuer und Subject der Kettenglieder vergleichen.
5. CA-Eigenschaften kontrollieren.
6. Vertrauensanker eindeutig festlegen.
7. Gültigkeitszeiten aller Zertifikate prüfen.
8. Hostnamen und Verwendungszweck prüfen.

TLS-Verbindung mit eigener CA-Datei prüfen

[TEST][FILE][SENS] openssl s_client -connect wiki.example.com:443 -servername wiki.example.com -verify_hostname wiki.example.com -verify_return_error -CAfile company-root-ca.pem

Lokales Zertifikat prüfen

[RO][FILE][SENS] openssl verify -CAfile company-root-ca.pem -untrusted company-intermediate-ca.pem -verify_hostname wiki.example.com server-cert.pem

Wichtig

Die Angabe von -CAfile gilt für diesen OpenSSL-Aufruf. Sie installiert die CA nicht automatisch in:

• Windows-Zertifikatspeicher;
• macOS-Schlüsselbund;
• Linux-Systemvertrauensspeicher;
• Browser-Vertrauensspeicher;
• Java-KeyStore;
• Container-Images.

Ein erfolgreicher OpenSSL-Test mit eigener CA-Datei beweist deshalb nicht, dass alle Anwendungen dieser CA vertrauen.

Ausschließlich TLS 1.2

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tls1_2

Ausschließlich TLS 1.3

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tls1_3

Minimalversion festlegen, sofern unterstützt

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -min_protocol TLSv1.2

Maximalversion festlegen

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -max_protocol TLSv1.2

Interpretation

Ein Versionsfehler kann auch durch einen zwischengeschalteten Proxy, Load Balancer oder TLS-Inspection-Dienst verursacht werden.

Verfügbare Cipher Suites des lokalen OpenSSL-Builds

[RO] openssl ciphers -v

Nur TLS-1.2-kompatible Auswahl untersuchen

[RO] openssl ciphers -v -tls1_2

Nur TLS-1.3-Cipher-Suites anzeigen, sofern unterstützt

[RO] openssl ciphers -v -tls1_3

Bestimmte TLS-1.2-Cipher-Auswahl testen

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tls1_2 -cipher 'ECDHE-RSA-AES128-GCM-SHA256'

Bestimmte TLS-1.3-Cipher-Suite testen

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tls1_3 -ciphersuites 'TLS_AES_128_GCM_SHA256'

Wichtiger Unterschied

Die tatsächlich verfügbaren Cipher Suites hängen von:

• OpenSSL-Version;
• aktivierten Providern;
• Sicherheitsstufe;
• Betriebssystempaket;
• Build-Konfiguration;
• kryptografischer Richtlinie

ab.

Eine einzelne funktionierende Cipher Suite beweist nicht, dass die gesamte TLS-Konfiguration sicher oder vollständig kompatibel ist.

HTTP/2 und HTTP/1.1 anbieten

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -alpn 'h2,http/1.1'

Mögliche Ausgabe:

ALPN protocol: h2

oder:

ALPN protocol: http/1.1

Nur HTTP/2 anbieten

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -alpn h2

Interpretation

ALPN bestimmt das Anwendungsprotokoll innerhalb der TLS-Verbindung. OpenSSL s_client führt danach nicht automatisch eine vollständige HTTP/2-Anfrage aus.

Für den Anwendungstest:

[TEST][SENS] curl --http2 -v https://example.com/

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -status

Die Option fordert während des TLS-Handshakes eine gestapelte OCSP-Antwort an.

Mögliche Ausgabe:

OCSP response:
...
Cert Status: good

Mögliche Ergebnisse

Kein OCSP Stapling bedeutet nicht automatisch, dass das Zertifikat gesperrt oder die TLS-Verbindung ungültig ist. Ob Stapling erforderlich ist, hängt von Zertifikat, Anwendung und Richtlinie ab.

Bei STARTTLS beginnt die Verbindung unverschlüsselt und wird anschließend innerhalb des Anwendungsprotokolls auf TLS umgestellt.

SMTP auf Port 25

[TEST][SENS] openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com

SMTP Submission auf Port 587

[TEST][SENS] openssl s_client -starttls smtp -connect mail.example.com:587 -servername mail.example.com

IMAP mit STARTTLS

[TEST][SENS] openssl s_client -starttls imap -connect mail.example.com:143 -servername mail.example.com

POP3 mit STARTTLS

[TEST][SENS] openssl s_client -starttls pop3 -connect mail.example.com:110 -servername mail.example.com

LMTP mit STARTTLS, sofern unterstützt

[TEST][SENS] openssl s_client -starttls lmtp -connect mail.example.com:24 -servername mail.example.com

Direktes TLS ohne STARTTLS

STARTTLS und direktes TLS dürfen nicht verwechselt werden.

LDAP mit STARTTLS

[TEST][SENS] openssl s_client -starttls ldap -connect ldap.example.com:389 -servername ldap.example.com

LDAPS mit direktem TLS

[TEST][SENS] openssl s_client -connect ldap.example.com:636 -servername ldap.example.com

PostgreSQL mit TLS-Aushandlung

[TEST][SENS] openssl s_client -starttls postgres -connect db.example.com:5432 -servername db.example.com

MySQL mit TLS-Aushandlung, sofern von der installierten OpenSSL-Version unterstützt

[TEST][SENS] openssl s_client -starttls mysql -connect db.example.com:3306 -servername db.example.com

Nicht jede OpenSSL- oder LibreSSL-Version unterstützt alle -starttls-Protokolle. Verfügbarkeit prüfen:

[RO] openssl s_client -help

Ein erfolgreicher TLS-Handshake beweist nicht, dass anschließend eine Datenbank- oder LDAP-Anmeldung erfolgreich ist.

[TEST][SENS] openssl s_client -proxy proxy.example.com:8080 -connect example.com:443 -servername example.com

OpenSSL sendet dabei eine HTTP-CONNECT-Anfrage an den Proxy und baut durch den Tunnel die TLS-Verbindung zum Zielserver auf.

Proxybenutzer angeben

[TEST][SENS] openssl s_client -proxy proxy.example.com:8080 -proxy_user max.mustermann -proxy_pass stdin -connect example.com:443 -servername example.com

Das Passwort wird über die angegebene Passwortquelle eingelesen.

Wichtiger Sicherheitshinweis

Die von s_client unterstützte Proxy-Basisauthentifizierung überträgt die Zugangsdaten vor dem TLS-Tunnel in leicht rückwandelbarer Base64-Form an den Proxy. Sie ist nur in entsprechend geschützten und autorisierten Umgebungen zu verwenden.

Direkt- und Proxytest vergleichen

Direkt:

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com

Über Proxy:

[TEST][SENS] openssl s_client -proxy proxy.example.com:8080 -connect example.com:443 -servername example.com

Unterschiedliche Zertifikate können auf TLS-Inspection oder unterschiedliche Netzwerkpfade hinweisen.

Clientzertifikat und Schlüssel getrennt

[TEST][FILE][SENS] openssl s_client -connect api.example.com:443 -servername api.example.com -cert client-cert.pem -key client-key.pem

Zusätzlich Serverzertifikat und Hostname verifizieren

[TEST][FILE][SENS] openssl s_client -connect api.example.com:443 -servername api.example.com -cert client-cert.pem -key client-key.pem -CAfile company-root-ca.pem -verify_hostname api.example.com -verify_return_error

Clientzertifikatskette angeben

[TEST][FILE][SENS] openssl s_client -connect api.example.com:443 -servername api.example.com -cert client-cert.pem -key client-key.pem -cert_chain client-chain.pem -build_chain

Die Optionen -cert_chain und -build_chain sind versionsabhängig.

Mögliche Fehler

• Clientzertifikat fehlt;
• privater Schlüssel passt nicht zum Zertifikat;
• Clientzertifikat abgelaufen;
• Extended Key Usage erlaubt keine Clientauthentifizierung;
• ausstellende Client-CA wird vom Server nicht vertraut;
• Zwischenzertifikat fehlt;
• falsches Dateiformat;
• verschlüsselter Schlüssel kann nicht geöffnet werden.

Private Schlüssel dürfen niemals in Tickets, BookStack-Seiten, Chatnachrichten oder Diagnoseausgaben eingefügt werden.

Allgemeinen privaten Schlüssel prüfen

[RO][FILE][SENS] openssl pkey -in server-key.pem -check -noout

Bei einem verschlüsselten Schlüssel wird normalerweise eine Passphrase abgefragt.

Nur öffentliche Schlüsselkomponente ausgeben

[RO][FILE][SENS] openssl pkey -in server-key.pem -pubout

Schlüsselinformation ohne private Bestandteile

[RO][FILE][SENS] openssl pkey -in server-key.pem -pubout -text_pub -noout

Nicht unkontrolliert verwenden

openssl pkey -in server-key.pem -text

Dieser Befehl kann private Schlüsselbestandteile ausgeben. Solche Ausgaben dürfen nicht in Logs, Terminalsitzungsaufzeichnungen oder Tickets gelangen.

Dateiberechtigungen prüfen

Linux:

[RO][FILE][SENS] stat server-key.pem

macOS:

[RO][FILE][SENS] stat -x server-key.pem

Windows:

[RO][FILE][SENS] Get-Acl .\server-key.pem

Die zuverlässige allgemeine Methode besteht darin, aus beiden Dateien den öffentlichen Schlüssel zu gewinnen und dessen DER-Darstellung zu hashen.

Hash des öffentlichen Schlüssels aus dem Zertifikat

[RO][FILE][SENS] openssl x509 -in server-cert.pem -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256

Hash des öffentlichen Schlüssels aus dem privaten Schlüssel

[RO][FILE][SENS] openssl pkey -in server-key.pem -pubout -outform DER | openssl dgst -sha256

Wenn beide SHA-256-Werte identisch sind, besitzen Zertifikat und privater Schlüssel denselben öffentlichen Schlüssel.

Beispiel

SHA2-256(stdin)= abcdef...
SHA2-256(stdin)= abcdef...

Warum nicht nur den RSA-Modulus vergleichen?

Der klassische Modulusvergleich funktioniert nur für bestimmte Schlüsselarten wie RSA. Der Vergleich des normalisierten öffentlichen Schlüssels funktioniert auch für andere von OpenSSL unterstützte Schlüsseltypen, beispielsweise EC-Schlüssel.

Gesamten CSR-Inhalt anzeigen

[RO][FILE][SENS] openssl req -in request.csr -noout -text

Subject anzeigen

[RO][FILE][SENS] openssl req -in request.csr -noout -subject

CSR-Signatur prüfen

[RO][FILE][SENS] openssl req -in request.csr -noout -verify

Öffentlichen Schlüssel des CSR ausgeben

[RO][FILE][SENS] openssl req -in request.csr -noout -pubkey

Zu prüfen

• Subject;
• gewünschte DNS-Namen;
• Subject Alternative Names;
• Schlüsseltyp;
• Schlüssellänge beziehungsweise Kurve;
• Signaturalgorithmus;
• erfolgreiche CSR-Signaturprüfung.

Ein CSR ist noch kein Zertifikat. Er enthält:

• Identitätsantrag;
• öffentlichen Schlüssel;
• angeforderte Erweiterungen;
• Signatur des zugehörigen privaten Schlüssels.

Er enthält nicht den privaten Schlüssel.

Öffentlichen Schlüssel aus dem CSR hashen

[RO][FILE][SENS] openssl req -in request.csr -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256

Öffentlichen Schlüssel aus dem privaten Schlüssel hashen

[RO][FILE][SENS] openssl pkey -in server-key.pem -pubout -outform DER | openssl dgst -sha256

Sind beide Werte identisch, gehört der private Schlüssel zum CSR.

Nach Ausstellung zusätzlich vergleichen

CSR ↔ privater Schlüssel
Zertifikat ↔ privater Schlüssel

Dadurch wird geprüft, ob die Zertifizierungsstelle tatsächlich das Zertifikat für den vorgesehenen Schlüssel ausgestellt hat.

PEM

PEM ist textbasiert und enthält Markierungen wie:

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

DER

DER ist ein binäres ASN.1-Format und besitzt keine lesbaren BEGIN-/END-Markierungen.

PEM-Zertifikat anzeigen

[RO][FILE][SENS] openssl x509 -in certificate.pem -inform PEM -noout -text

DER-Zertifikat anzeigen

[RO][FILE][SENS] openssl x509 -in certificate.der -inform DER -noout -text

DER nach PEM konvertieren

[CHANGE][FILE][SENS] openssl x509 -in certificate.der -inform DER -out certificate.pem -outform PEM

PEM nach DER konvertieren

[CHANGE][FILE][SENS] openssl x509 -in certificate.pem -inform PEM -out certificate.der -outform DER

Die Dateiendung allein beweist das Format nicht. Dateien mit .cer oder .crt können PEM oder DER enthalten.

PKCS#12-Dateien verwenden häufig die Endungen:

.p12
.pfx

Sie können enthalten:

• Zertifikat;
• Zwischenzertifikate;
• Root-Zertifikate;
• privaten Schlüssel;
• Metadaten.

Inhalt anzeigen, aber keine privaten Schlüssel ausgeben

[RO][FILE][SENS] openssl pkcs12 -in bundle.p12 -info -noout

Nur Zertifikate anzeigen, keine privaten Schlüssel

[RO][FILE][SENS] openssl pkcs12 -in bundle.p12 -nokeys

Nur das Client- beziehungsweise Leaf-Zertifikat extrahieren

[CHANGE][FILE][SENS] openssl pkcs12 -in bundle.p12 -clcerts -nokeys -out client-cert.pem

CA-Zertifikate extrahieren

[CHANGE][FILE][SENS] openssl pkcs12 -in bundle.p12 -cacerts -nokeys -out ca-chain.pem

Privaten Schlüssel extrahieren

[CHANGE][FILE][SENS] openssl pkcs12 -in bundle.p12 -nocerts -out client-key-encrypted.pem

Dieser Vorgang erzeugt eine Datei mit privatem Schlüssel und ist besonders sensibel. Die Ausgabedatei sollte verschlüsselt und mit streng beschränkten Dateirechten gespeichert werden.

Unverschlüsselten privaten Schlüssel exportieren

Optionen wie -nodes beziehungsweise das neuere -noenc können unverschlüsselte private Schlüssel erzeugen. Das sollte nur in begründeten Ausnahmefällen, mit dokumentierter Freigabe und geeigneten Dateirechten erfolgen.

Zertifikatsfingerabdruck

[RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -fingerprint -sha256

Hash der gesamten Datei

[RO][FILE][SENS] openssl dgst -sha256 server-cert.pem

Diese beiden Werte sind nicht dasselbe:

Zwei PEM-Dateien können dasselbe Zertifikat enthalten, aber wegen unterschiedlicher Zeilenenden oder Formatierung unterschiedliche Dateihashes besitzen. Der Zertifikatsfingerabdruck bleibt dagegen identisch.

Betriebssystemspezifischer Dateihash

Windows:

[RO][FILE][SENS] Get-FileHash .\server-cert.pem -Algorithm SHA256

Linux:

[RO][FILE][SENS] sha256sum server-cert.pem

macOS:

[RO][FILE][SENS] shasum -a 256 server-cert.pem

TLS-Zustandswechsel anzeigen

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -state

TLS-Protokollnachrichten anzeigen

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -msg

Umfangreicher Trace, sofern unterstützt

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -trace

TLS-Erweiterungen anzeigen

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tlsextdebug

Wichtiger Hinweis

-debug, -msg und -trace können sehr umfangreiche Hexadezimal- und Protokollausgaben erzeugen. Sie sollten erst verwendet werden, wenn:

• der normale s_client-Test nicht ausreicht;
• der Fehler reproduzierbar ist;
• die Ausgabe geschützt gespeichert wird;
• keine geheimen Anwendungsdaten eingegeben werden.

IPv4 erzwingen

[TEST][SENS] openssl s_client -4 -connect example.com:443 -servername example.com

IPv6 erzwingen

[TEST][SENS] openssl s_client -6 -connect example.com:443 -servername example.com

Direkte IPv6-Adresse

[TEST][SENS] openssl s_client -connect '[2001:db8::20]:443' -servername example.com

Bei einer IPv6-Adresse in host:port-Schreibweise muss die Adresse in eckige Klammern gesetzt werden.

Interpretation

1. DNS prüfen

Windows:

[RO] Resolve-DnsName example.com

Linux:

[RO] dig example.com

macOS:

[RO] dig example.com

2. TCP-Port prüfen

Windows:

[TEST] Test-NetConnection example.com -Port 443

Linux und macOS:

[TEST] nc -vz example.com 443

3. TLS mit SNI prüfen

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com

4. Zertifikatsprüfung erzwingen

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -verify_return_error

5. Zertifikatsliste anzeigen

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -showcerts

6. TLS-Versionen getrennt prüfen

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tls1_2

[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tls1_3

7. Anwendung prüfen

[TEST][SENS] curl -v https://example.com/

8. Logs vergleichen

• Reverse Proxy;
• Webserver;
• Load Balancer;
• Firewall;
• Anwendung;
• Zertifikatsverwaltung;
• Systemzeit.

Vorbereitung

1. Erwarteten Hostnamen, Ziel-IP und Port dokumentieren.
2. Klären, ob direktes TLS oder STARTTLS verwendet wird.
3. OpenSSL- beziehungsweise LibreSSL-Version prüfen.
4. Erwartete Zertifizierungsstelle und Zertifikatsnamen ermitteln.
5. Systemzeit und Zeitzone kontrollieren.
6. Private Schlüssel und Passwortquellen schützen.

Verbindung

7. DNS-Auflösung prüfen.
8. TCP-Port prüfen.
9. TLS-Verbindung mit richtigem SNI aufbauen.
10. Tatsächlich ausgehandelte TLS-Version und Cipher Suite dokumentieren.
11. ALPN bei HTTP-Diensten prüfen.

Zertifikat

12. Zertifikatsprüffehlermeldungen beachten.
13. Prüfung mit -verify_return_error erzwingen.
14. Hostnamen mit -verify_hostname prüfen.
15. Serverzertifikate mit -showcerts anzeigen.
16. Leaf- und Zwischenzertifikate getrennt untersuchen.
17. SAN, Issuer, Subject und Gültigkeit prüfen.
18. Kette mit openssl verify lokal nachvollziehen.

Vertiefung

19. TLS 1.2 und TLS 1.3 getrennt testen.
20. IPv4 und IPv6 vergleichen.
21. Direkt- und Proxyverbindung vergleichen.
22. Bei mTLS Clientzertifikat und Schlüsselzuordnung prüfen.
23. Bei STARTTLS das richtige Anwendungsprotokoll angeben.
24. Nur bei Bedarf -state, -msg oder -trace verwenden.

Validierung

25. HTTPS zusätzlich mit curl prüfen.
26. Server-, Proxy- und Firewall-Logs vergleichen.
27. Bei Netzwerkverdacht Paketmitschnitt erstellen.
28. Nach einer Änderung exakt denselben Test wiederholen.
29. Diagnoseausgaben vor Weitergabe auf sensible Daten prüfen.
30. Temporär extrahierte Schlüssel- oder Zertifikatsdateien sicher behandeln.