OpenSSL s_client : le 403 du proxy survient avant le TLS de la destination
Interprétez un 403 sur CONNECT via un proxy OpenSSL comme un échec de l'étape de tunnel et ne diagnostiquez pas le certificat de la destination à partir d'une poignée de main qui n'a jamais commencé.
Si openssl s_client reçoit un HTTP 403 en réponse à sa requête CONNECT via le proxy, commencez par ce refus. Le tunnel demandé n'a pas été établi.
Avec -proxy, s_client demande d'abord au proxy HTTP de se connecter à la destination indiquée par -connect. Seule une réponse CONNECT réussie transforme cet échange en tunnel pour la poignée de main TLS de la destination.
Cet ordre explique une sortie autrement déroutante : une erreur du proxy suivie d'en-têtes liés à TLS, aucun certificat de pair, ou une ligne de vérification apparemment rassurante. Ces champs ne prouvent pas que le certificat de la destination a été reçu et vérifié. L'opération s'est arrêtée à une étape antérieure.
Notez la réponse du proxy ainsi que l'hôte et le port de destination demandés. Un 403 attire l'attention sur la décision d'accès du proxy ; un 407 demande une authentification auprès du proxy. Ni l'un ni l'autre ne se règle en désactivant la vérification du certificat de la destination.
Lorsqu'il est permis d'inspecter l'échange, la sortie -debug de s_client peut aider à révéler le refus. Gardez les identifiants du proxy hors des traces partagées. Un tunnel réussi nécessiterait ensuite sa propre évaluation TLS et de certificats, mais il n'y a aucune chaîne de certificats cible à diagnostiquer tant que cette étape n'a pas été réellement atteinte.