OpenSSL s_client: proxyaren 403a helmugako TLSa baino lehen gertatzen da
Ulertu OpenSSL proxy baten CONNECT 403a tunel-faseko hutsegite gisa, eta ez diagnostikatu helmugako ziurtagiria inoiz hasi ez zen handshake batetik abiatuta.
openssl s_client -ek proxy CONNECT eskaerari erantzunez HTTP 403 jasotzen badu, hasi ukapen horretatik. Eskatutako tunela ez da ezarri.
-proxy aukerarekin, s_client-ek lehenengo HTTP proxyari eskatzen dio -connect bidez zehaztutako helmugara konektatzeko. CONNECT erantzun arrakastatsu batek soilik bihurtzen du truke hori helmugako TLS handshake-rako tunel.
Ordena horrek bestela nahasgarria den irteera azaltzen du: proxy errore bat, ondoren TLSrekin lotutako goiburuak, pareko ziurtagiririk ez, edo itxuraz lasaigarria den egiaztapen-lerro bat. Eremu horiek ez dute frogatzen helmugako ziurtagiria jaso eta egiaztatu denik. Eragiketa lehenagoko fase batean gelditu zen.
Erregistratu proxyaren erantzuna eta eskatutako helmugako ostalaria eta ataka. 403 batek proxyaren sarbide-erabakira bideratzen du arreta; 407 batek proxyaren autentifikazioa eskatzen du. Biak ez dira konpontzen helmugako ziurtagiria egiaztatzea desgaituta.
Trukea ikuskatzeko baimena dagoenean, s_client-en -debug irteerak ukapena agerian jartzen lagun dezake. Eduki proxy-kredentzialak partekatutako aztarnetatik kanpo. Tunel arrakastatsu batek geroago bere TLS eta ziurtagirien ebaluazioa beharko luke, baina ez dago helmugako ziurtagiri-katerik diagnostikatzeko fase horretara benetan iritsi arte.