OpenSSL s_client: de proxy-403 komt foar de TLS fan it doel
Ynterpretearje in 403 op CONNECT fia in OpenSSL-proxy as in flater yn 'e tunnelstap en diagnostearje gjin sertifikaat fan it doel op grûn fan in hânskodding dy't nea begûn is.
As openssl s_client in HTTP 403 krijt as antwurd op syn CONNECT-fersyk fia de proxy, begjin dan by dy wegering. De frege tunnel is net oanlein.
Mei -proxy freget s_client earst de HTTP-proxy om ferbining te meitsjen mei it doel dat oanjûn is troch -connect. Allinnich in slagge CONNECT-antwurd feroaret dy útwikseling yn in tunnel foar de TLS-hânskodding fan it doel.
Dizze folchoarder ferklearret in oars betiizjende útfier: in proxyflater folge troch TLS-relatearre kopteksten, gjin sertifikaat fan 'e tsjinpartij, of in skynber gerêststellende ferifikaasjeline. Dy fjilden bewize net dat it sertifikaat fan it doel ûntfongen en ferifiearre is. De operaasje stoppe yn in eardere stap.
Skriuw it antwurd fan 'e proxy en de frege host en poarte fan it doel op. In 403 rjochtet de oandacht op 'e tagongsbeslissing fan 'e proxy; in 407 freget proxy-autentikaasje. Gjin fan beide wurdt reparearre troch de ferifikaasje fan it sertifikaat fan it doel út te skeakeljen.
As it tastien is de útwikseling te ûndersykjen, kin de -debug-útfier fan s_client helpe om de wegering bleat te lizzen. Hâld eventuele proxy-sertifikaten bûten dielde spoaren. In slagge tunnel soe dêrnei noch altyd syn eigen TLS- en sertifikaatbeoardieling nedich hawwe, mar der is gjin doelsertifikaatkeatling om te diagnostearjen oant dy stap wier berikt is.