Les ensembles de CA de Cargo pour le proxy et le serveur de paquets
Appliquez cainfo et proxy-cainfo de Cargo à la bonne connexion TLS au lieu de confondre toutes les erreurs de certificat du proxy.
Avec un proxy HTTPS et une source de paquets HTTPS, Cargo peut vérifier deux connexions TLS avec des ensembles de CA différents :
[http]
proxy = "https://proxy.example:8443"
proxy-cainfo = "/path/to/proxy-ca.pem"
cainfo = "/path/to/origin-ca.pem"Remplacez le point de terminaison et les chemins par vos valeurs approuvées. Ce proxy possède volontairement une écoute TLS ; un proxy HTTP ordinaire ne devient pas HTTPS parce que la source de paquets utilise HTTPS.
| Étape de l’échec | Paramètre de confiance à examiner |
|---|---|
| TLS du proxy, avant l’existence d’un tunnel vers la destination | http.proxy-cainfo, qui se rabat sur http.cainfo s’il n’est pas défini séparément. |
| Certificat de destination après établissement du tunnel | http.cainfo pour la chaîne de confiance de la destination. |
Les variables correspondantes sont CARGO_HTTP_PROXY_CAINFO et CARGO_HTTP_CAINFO. Utilisez l’autorité approuvée appropriée ; copier un certificat quelconque dans les deux fichiers ne permet pas d’identifier la connexion en cause.
Un proxy HTTP en clair transportant CONNECT n’a pas de certificat TLS d’écoute proxy à vérifier. Une erreur de destination dans ce cas ne se corrige pas en inventant un fichier CA de proxy. Vérifiez aussi qu’un chemin configuré existe dans le conteneur ou la tâche CI réellement utilisé, et tenez compte du comportement du système d’exploitation et du moteur TLS en comparant les environnements.
Gardez la vérification activée. Elle fournit le contrôle d’identité nécessaire pour distinguer le service attendu d’un transfert qui se poursuit simplement.