OpenSSL s_client: dumarating ang 403 ng proxy bago ang TLS ng destinasyon
Unawain ang 403 sa CONNECT sa pamamagitan ng proxy ng OpenSSL bilang pagkabigo sa yugto ng tunnel at huwag i-diagnose ang sertipiko ng destinasyon mula sa handshake na hindi kailanman nagsimula.
Kung makatanggap ang openssl s_client ng HTTP 403 bilang tugon sa request nitong CONNECT sa proxy, magsimula sa pagtanggi na iyon. Hindi naitatag ang hiniling na tunnel.
Sa -proxy, hihilingin muna ng s_client sa HTTP proxy na kumonekta sa destinasyong tinukoy ng -connect. Tanging matagumpay na tugon ng CONNECT ang nagbabago sa palitan na iyon tungo sa isang tunnel para sa TLS handshake ng destinasyon.
Ipinapaliwanag ng pagkakasunod-sunod na ito ang kung hindi ay nakakalitong output: isang error ng proxy na sinusundan ng mga pamagat na may kaugnayan sa TLS, walang sertipiko ng kapares, o isang linyang beripikasyon na tila nagpapatahimik. Hindi pinapatunayan ng mga field na iyon na natanggap at na-verify ang sertipiko ng destinasyon. Huminto ang operasyon sa mas maagang yugto.
Itala ang tugon ng proxy at ang hiniling na host at port ng destinasyon. Ang 403 ay nagtuturo ng pansin sa desisyon ng proxy sa pag-access; ang 407 ay humihiling ng pagpapatunay sa proxy. Wala sa dalawa ang naayos sa pamamagitan ng pagpatay sa beripikasyon ng sertipiko ng destinasyon.
Kapag pinapayagan ang pagsusuri sa palitan, ang output ng -debug ng s_client ay makatutulong na ilantad ang pagtanggi. Panatilihing wala sa mga ibinahaging trace ang anumang kredensyal ng proxy. Ang matagumpay na tunnel ay mangangailangan pa rin ng sariling pagtatasa ng TLS at sertipiko pagkatapos, ngunit walang chain ng sertipiko ng target na maaaring i-diagnose hanggang sa aktwal na maabot ang yugtong iyon.