Avant de modifier un bundle de CA, identifiez la négociation TLS qui a échoué. Le certificat du proxy et celui du site peuvent être vérifiés sur des connexions distinctes.

Proxy et destinationVérifications TLS
Proxy HTTP transportant une connexion vers un site HTTPSAprès CONNECT, vérifiez le certificat de destination à travers le tunnel.
Proxy HTTPS transportant une connexion vers un site HTTPSVérifiez d’abord TLS vers le proxy ; une fois le tunnel ouvert, vérifiez la session TLS distincte vers la destination.

La trace détaillée permet d’identifier le nom d’hôte demandé et la dernière négociation terminée. Une erreur de certificat du proxy HTTPS peut survenir avant que le site soit contacté. Vérifiez le nom prévu pour cette connexion, la période de validité du certificat, l’horloge locale, la chaîne attendue et le magasin de confiance approuvé. Incluez dans l’examen toute interception TLS configurée volontairement ou tout certificat racine ajouté.

curl propose des options de CA séparées pour ces deux connexions :

curl --proxy https://proxy.example:8443 --proxy-cacert proxy-ca.pem --cacert site-ca.pem https://example.com/

--proxy-cacert fournit la base de confiance pour le proxy ; --cacert celle de la destination. Remplacez le point de connexion et les fichiers de l’exemple par ceux du dispositif de confiance souhaité. Des bundles personnalisés sont inutiles si la confiance du système suffit déjà.

Remplacer un nom d’hôte par une IP arbitraire change la correspondance du certificat. Ignorer la vérification peut masquer l’échec sans établir l’identité de l’autre extrémité. Pour un proxy inconnu, une demande d’installation de sa CA racine ne suffit pas à justifier la confiance.

Un port qui refuse la connexion ou un CONNECT rejeté relèvent d’une étape antérieure ; changer les certificats ne les corrigera pas. À l’inverse, une erreur HTTP du site après la validation TLS de la destination concerne la réponse reçue, pas un nouvel ajustement des CA.

Articles similaires