Een websitecertificaat via een HTTP-proxy met OpenSSL inspecteren
Gebruik OpenSSL s_client via een HTTP CONNECT-proxy en houd de bestemmingsnaam, SNI en certificaatverificatie op elkaar afgestemd.
Gebruik een geïnstalleerde OpenSSL s_client die -proxy ondersteunt. Voor een geautoriseerd HTTP CONNECT-eindpunt:
openssl s_client -proxy proxy.example:3128 -connect example.com:443 -servername example.com -verify_hostname example.com -verify_return_error -showcertsVervang het proxyadres en gebruik de beoogde bestemmingsnaam consequent. Kies voor een test van een openbare bestemming via een proxy die je mag selecteren een HTTP-kandidaat uit de HTTP-proxylijst. -connect kiest het doel, -servername stuurt SNI voor de TLS-virtuele host en -verify_hostname controleert de identiteit. SNI alleen is geen hostnaamverificatie. Raadpleeg de handleiding voor de geïnstalleerde versie wanneer je opties aanpast.
-showcerts toont wat de server heeft gestuurd en verklaart niet dat de keten vertrouwd is. -verify_return_error laat verificatiefouten de handshake beëindigen; anders kan de diagnostische client na fouten doorgaan. Gebruik voor een private dienst goedgekeurd CA-materiaal in plaats van een willekeurig gedownload certificaat te vertrouwen.
| Resultaat | Fase |
|---|---|
| 407 | Proxy-authenticatie vóór TLS van de bestemming. |
| Geblokkeerde CONNECT-bestemming | Proxybeleid voor de bestemming. |
| Certificaat ontvangen en verificatie geprobeerd | TLS-uitwisseling van de bestemming door de geaccepteerde tunnel. |
Gebruik met OpenSSL 3.x en een HTTP-proxy met Basic-authenticatie de s_client-proxyaccountopties en behoud de bestemmingsverificatie.
Een endpoint dat alleen SOCKS biedt, levert niet de HTTP-proxyinterface die deze opdracht gebruikt. Bij geautoriseerde TLS-interceptie kan het getoonde certificaat door die tussenpersoon zijn uitgegeven. Vergelijk de uitgever en de bedoelde vertrouwensrelatie voordat je het verschil aan een defecte website toeschrijft.