Verwenden Sie ein installiertes OpenSSL s_client, das -proxy unterstützt. Für einen autorisierten HTTP-CONNECT-Endpunkt:

openssl s_client -proxy proxy.example:3128   -connect example.com:443 -servername example.com   -verify_hostname example.com -verify_return_error -showcerts

Ersetzen Sie die Proxy-Adresse und verwenden Sie den vorgesehenen Zielnamen durchgängig. Für einen Test eines öffentlichen Ziels über einen Proxy, den Sie auswählen dürfen, wählen Sie einen HTTP-Kandidaten aus der HTTP-Proxy-Liste. -connect wählt das Ziel, -servername sendet SNI für dessen virtuelles TLS-Host, und -verify_hostname prüft die Identität. SNI allein ist keine Hostnamenprüfung. Lesen Sie beim Anpassen der Optionen das Handbuch für die installierte Version.

-showcerts zeigt, was der Server gesendet hat, und erklärt nicht, dass die Kette vertrauenswürdig ist. -verify_return_error beendet den Handshake bei Verifikationsfehlern; andernfalls kann der Diagnoseclient nach Fehlern fortfahren. Verwenden Sie für einen privaten Dienst genehmigtes CA-Material, statt einem beliebig heruntergeladenen Zertifikat zu vertrauen.

ErgebnisPhase
407Proxy-Authentifizierung vor dem TLS des Ziels.
Abgelehntes CONNECT-ZielProxy-Zielrichtlinie.
Zertifikat empfangen und Prüfung versuchtTLS-Austausch des Ziels durch den akzeptierten Tunnel.

Bei OpenSSL 3.x und einem HTTP-Proxy mit Basic-Authentifizierung verwenden Sie die Proxy-Kontooptionen von s_client, während die Zielprüfung erhalten bleibt.

Ein reiner SOCKS-Endpunkt stellt nicht die HTTP-Proxy-Schnittstelle bereit, die dieser Befehl verwendet. Bei autorisierter TLS-Interception kann das angezeigte Zertifikat von diesem Vermittler ausgestellt worden sein. Vergleichen Sie seinen Aussteller und die vorgesehene Vertrauensregelung, bevor Sie den Unterschied einer fehlerhaften Website zuschreiben.

Ähnliche Artikel