Kontrolu retejan atestilon per HTTP-prokurilo kun OpenSSL
Uzu OpenSSL s_client tra HTTP CONNECT-prokurilo kaj vicigu la celan nomon, SNI kaj atestilan kontrolon.
Uzu instalitan OpenSSL s_client kiu subtenas -proxy. Por rajtigita HTTP CONNECT-finpunkto:
openssl s_client -proxy proxy.example:3128 -connect example.com:443 -servername example.com -verify_hostname example.com -verify_return_error -showcertsAnstataŭigu la prokurilan adreson kaj uzu la celan nomon konsekvence. Por publika celtesto per elektebla prokurilo, elektu HTTP-kandidaton el la HTTP-prokura listo. -connect elektas la celon, -servername sendas SNI por ĝia TLS-virtuala gastiganto, kaj -verify_hostname kontrolas la identecon. SNI sola ne estas gastignoma kontrolo. Konsultu la manlibron de la instalita eldono kiam vi adaptas opciojn.
-showcerts montras kion sendis la servilo, ne deklaras ke la ĉeno estas fidinda. -verify_return_error igas kontrolerarojn fini la manpremon; alie la diagnoza kliento povas daŭrigi post eraroj. Por privata servo uzu aprobitan CA-materialon anstataŭ fidi arbitre elŝutitan atestilon.
| Rezulto | Etapo |
|---|---|
| 407 | Prokurila aŭtentigo antaŭ la celloka TLS. |
| Malakceptita CONNECT-celo | Prokurila celpolitiko. |
| Atestilo ricevita kaj kontrolo provita | La cela TLS-interŝanĝo tra la akceptita tunelo. |
Kun OpenSSL 3.x kaj Basic-aŭtentiga HTTP-prokurilo, uzu la s_client-prokurilajn kontajn opciojn konservante celan kontrolon.
SOCKS-nura finpunkto ne liveras la HTTP-prokuran interfacon uzatan de ĉi tiu komando. Kun rajtigita TLS-interkapto, la montrita atestilo povas esti eldonita de tiu peranto. Komparu ĝian eldonanton kaj la celitan fidaranĝon antaŭ atribui diferencon al rompita retejo.