Ignorer les erreurs de certificat SSL avec curl

La commande est « curl -k ». Si c'est vraiment tout ce dont vous aviez besoin, vous pouvez vous arrêter là.

La raison pour laquelle le reste de cet article existe est que ** «-k » ne résout pas un problème de certificat — il désactive simplement la vérification qui l'a détecté.** La documentation de curl elle-même est exceptionnellement claire à ce sujet, indiquant qu’elle « recommande vivement d’éviter cette pratique » et que vous ne devriez « jamais ignorer la vérification en production ». C’est eux qui mettent l’accent, pas nous.

Nous sommes Geonode et nous vendons des proxys, mais en toute honnêteté, ce problème n’a pratiquement rien à voir avec notre produit. Les erreurs de certificat relèvent de votre machine, de son magasin de certificats et du serveur. Il existe une exception : un proxy d’interception sur un réseau d’entreprise figure parmi les causes les plus courantes de cette erreur, et une section y est consacrée ci-dessous ; mais vous ne résoudrez pas une erreur de certificat en achetant quoi que ce soit, que ce soit chez nous ou ailleurs.

Ce qui mérite que vous y consacriez du temps, c’est le diagnostic. Les erreurs de certificat ont un nombre restreint de causes spécifiques, et pour la plupart d’entre elles, il existe une solution qui prend à peu près autant de temps que de taper « -k » tout en laissant la vérification activée. Un certificat intermédiaire manquant, un ensemble de certificats d’autorité de certification (CA) obsolète, un certificat racine d’entreprise que curl ne reconnaît pas, un certificat expiré, une incompatibilité de nom d’hôte. Chacune présente une signature distincte et une réponse distincte.

Le risque concret de recourir par réflexe à -k n’est pas abstrait. Il réside dans le fait que le drapeau soit copié dans un script, que ce script soit mis en production, et qu’une vérification qui aurait permis de détecter un véritable problème d’interception ne s’exécute plus — à un endroit où personne ne se souvient qu’elle a jamais été désactivée.

Tout ce qui suit concernant le comportement de curl provient de la documentation de curl sur les certificats SSL et du livre consacré à curl.

La commande que tout le monde attendait

La voici, avec ses variantes.

# Skip verification of the server's certificate
curl -k https://example.com

# Same thing, long form
curl --insecure https://example.com

# Skip verification for the proxy's certificate as well
curl -k --proxy-insecure -x https://proxy.example.com:8080 https://example.com

,

-k

et --insecure

correspondent à la même option. --proxy-insecure

est une option distincte qui s'applique au certificat du proxy HTTPS lui-même plutôt qu'à celui de la destination — il s'agit de deux vérifications indépendantes et la désactivation de l'une n'entraîne pas celle de l'autre.

Examinez l’erreur avant de la masquer

Avant d’utiliser le drapeau, prenez dix secondes pour déterminer ce qui a réellement échoué :

curl -v https://example.com

Le journal détaillé affiche la négociation TLS et la raison précise de l’échec de la vérification. « Impossible d’obtenir le certificat de l’émetteur local » est un problème très différent de « le certificat a expiré », qui est lui-même différent d’une non-correspondance de nom d’hôte — et chacun nécessite une solution différente.

Examinez de plus près le certificat que le serveur présente réellement :

curl -vI https://example.com 2>&1 | grep -A 20 "Server certificate"

Cela affiche le sujet, l’émetteur et les dates de validité. Souvent, la réponse est visible immédiatement : le certificat a expiré mardi dernier, ou il a été émis pour un nom d’hôte différent, ou encore l’émetteur est une organisation dont vous n’avez jamais entendu parler — ce qui signifie généralement que quelque chose intercepte votre trafic.

Une bonne habitude à prendre

Commencez par diagnostiquer, puis décidez. La commande « -k

» est un outil légitime pour effectuer un test ponctuel sur un serveur que vous contrôlez. Cela devient problématique lorsque c’est un réflexe plutôt qu’une conclusion, car le drapeau ne précise pas ce qu’il a supprimé.

Ce que l'option -k désactive réellement

Bien plus que ce que la plupart des gens imaginent, et c'est là un point qu'il convient de bien retenir.

Par défaut, selon la documentation de curl, curl effectue la vérification du certificat en « vérifiant la signature et en s'assurant que le certificat a bien été émis pour le nom de serveur indiqué dans l'URL ».

Cette phrase décrit deux vérifications distinctes, et l’option --k désactive les deux.

Première vérification : la chaîne de signature

Cette chaîne de certificats remonte-t-elle jusqu’à une autorité de certification à laquelle votre système fait confiance ? C’est ce qui prouve que le certificat a été émis par une autorité de certification reconnue, plutôt que généré par n’importe qui disposant de cinq minutes et d’une installation d’OpenSSL.

Sans cela, n’importe quel certificat est accepté. Un certificat auto-signé créé par n’importe qui se trouvant entre vous et le serveur est accepté aussi facilement qu’un certificat provenant d’une véritable autorité de certification.

Vérification n° 2 : le nom d’hôte

Ce certificat appartient-il réellement à l’hôte que vous avez demandé ? Un certificat valide et correctement émis pour attacker.example n’est toujours pas un certificat pour bank.example, et c’est la vérification du nom d’hôte qui garantit cela.

Sans elle, un certificat authentique pour n’importe quel domaine est accepté pour n’importe quelle connexion.

Ce qui reste

La connexion est toujours chiffrée. Le protocole TLS négocie toujours un algorithme de chiffrement et le trafic ne circule pas en clair sur le réseau.

Mais le chiffrement sans authentification vous protège d’un observateur passif, et non d’un observateur actif. Le manuel curl en expose clairement les conséquences : avec une vérification affaiblie, « vos communications peuvent être sujettes à des attaques de type « Man-In-The-Middle » ». Toute personne en mesure d’intercepter la connexion peut présenter son propre certificat, mettre fin à votre session TLS, lire et modifier tout le contenu, puis établir une nouvelle connexion. Vous verriez l’icône du cadenas indiquant que la connexion est chiffrée, mais vous n’en comprendriez pas la signification.

Pourquoi cela est-il plus important dans les scripts ?

En mode interactif, vous savez que vous avez tapé -k et vous savez pourquoi. Dans un script, ce drapeau persiste bien après que la raison a été oubliée. Les identifiants sont envoyés par son intermédiaire. Les données reviennent par ce biais et sont considérées comme fiables.

Si vous devez l’utiliser dans le cadre d’une automatisation, ajoutez un commentaire expliquant pourquoi et ce qu’il faudrait modifier pour le supprimer. Cette simple ligne fait la différence entre une décision mûrement réfléchie et une décision invisible.

Pourquoi cette erreur s'affiche-t-elle ?

Cinq causes couvrent la quasi-totalité des cas, chacune présentant des caractéristiques propres dans le journal détaillé.

1. Certificat intermédiaire manquant

Il s'agit de la cause la plus courante ; il s'agit d'une mauvaise configuration du serveur plutôt que d'un problème de votre côté.

Chaîne de certificats : le certificat du serveur est signé par une autorité intermédiaire, elle-même signée par une racine à laquelle votre système fait confiance. Le serveur est censé envoyer son propre certificat ainsi que les certificats intermédiaires. S’il n’envoie que le sien, votre client ne peut pas compléter la chaîne.

Les navigateurs masquent souvent ce problème en récupérant automatiquement les certificats intermédiaires manquants ou en les mettant en cache à partir de visites précédentes. Ce n’est pas le cas de curl. Le symptôme caractéristique est donc un site qui fonctionne parfaitement dans un navigateur mais qui échoue avec curl — et le serveur est bel et bien mal configuré ; le navigateur se montre indulgent.

Solution : demandez à la personne qui gère le serveur de configurer la chaîne complète. S’il s’agit de votre serveur, cette modification ne prend que cinq minutes et résout d’un seul coup tous les problèmes rencontrés par les clients autres que les navigateurs.

2. Ensemble de certificats d’autorité de certification (CA) obsolète

La liste des autorités de certification de confiance de votre système est obsolète, ce qui empêche la reconnaissance d’un certificat émis en toute légitimité. Ce problème est courant sur les systèmes anciens, les images de conteneurs minimalistes et les machines virtuelles à longue durée de vie.

Solution : mettez à jour le paquet de certificats d’autorité de certification du système.

3. Inspection TLS d’entreprise

Le réseau de votre entreprise déchiffre et rechiffre le trafic, en présentant son propre certificat. Voir la section dédiée ci-dessous.

4. Certificat auto-signé

Serveurs de développement, outils internes, appliances. Il n’y a pas d’autorité à laquelle se rattacher, car le certificat s’est signé lui-même.

Solution : indiquez explicitement ce certificat à curl à l’aide de --cacert, plutôt que de désactiver la vérification de manière globale.

5. Certificat réellement expiré ou incorrect

Parfois, la vérification est correcte. Le certificat a expiré, ou il a été émis pour un nom d’hôte différent, ou encore le site est réellement mal configuré.

Solution : prévenez la personne en charge du site. Utiliser -k dans ce cas revient à ignorer délibérément des informations exactes.

Interprétation du résultat détaillé

« Impossible d’obtenir le certificat de l’émetteur local » renvoie aux causes 1, 2 ou 3. « Le certificat a expiré » correspond à la cause 5 et ne nécessite aucune interprétation. Une non-correspondance du nom d’hôte relève également de la cause 5. Un nom d’émetteur inconnu correspond à la cause 3 et mérite d’être examiné de près plutôt que d’être contourné.

Les solutions par ordre de priorité

De la meilleure à la pire. Parcourez la liste et arrêtez-vous dès qu’une solution fonctionne.

1. Corrigez le serveur

S’il s’agit d’un certificat intermédiaire manquant et que vous contrôlez le serveur, configurez la chaîne complète. Cela résout le problème pour tous les clients, de manière permanente, et c’est la seule solution qui améliore également l’expérience des autres utilisateurs.

2. Mettez à jour votre bundle CA

# Debian / Ubuntu
sudo apt-get update && sudo apt-get install --reinstall ca-certificates

# RHEL / Fedora
sudo update-ca-trust

# Alpine
apk add --no-cache ca-certificates && update-ca-certificates

Cette dernière solution résout une très grande partie des erreurs de certificat au sein des conteneurs, où les images minimalistes sont souvent fournies sans aucun bundle CA.

3. Indiquez à curl le bon certificat

Pour un certificat auto-signé ou interne, fournissez-le explicitement. La vérification reste activée : vous avez simplement indiqué à curl à quoi faire confiance pour cette connexion.

# A specific CA certificate file
curl --cacert /path/to/ca.crt https://internal.example.com

# A directory of certificates
curl --capath /etc/ssl/certs https://internal.example.com

C’est la bonne solution pour les services internes et les environnements de développement, et cela ne demande guère plus d’effort que -k

. La différence est que cela échoue toujours si un élément inattendu intercepte la connexion, ce qui est justement l’intérêt de la vérification.

4. Définir le certificat dans l’environnement

Pour une session ou un conteneur entier, la documentation de curl indique que vous pouvez « spécifier votre propre fichier de certificat d’autorité de certification (CA) en définissant la variable d’environnement CURL_CA_BUNDLE

sur le chemin de votre choix », et que «SSL_CERT_FILE

et SSL_CERT_DIR

sont également pris en charge ».

export CURL_CA_BUNDLE=/path/to/corporate-ca-bundle.crt
curl https://example.com   # verification on, using your bundle

Ces deux dernières variables sont également prises en charge par un large éventail d’autres outils, ce qui en fait un bon moyen de configurer l’ensemble d’un environnement en une seule fois plutôt que d’avoir à le faire outil par outil.

5. Ajouter le certificat au magasin système

Pour un certificat racine d’entreprise que vous utiliserez régulièrement, installez-le une seule fois au niveau du système. Tous les outils présents sur la machine fonctionneront alors normalement.

# Debian / Ubuntu
sudo cp corporate-root.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

6. Et seulement alors, utilisez l’option -k

Et si vous le faites, limitez son champ d’application autant que possible : une commande, un hôte, avec un commentaire expliquant pourquoi.

Inspection TLS en entreprise

C'est la cause qui déroute le plus les utilisateurs, car tout semble fonctionner normalement.

Que se passe-t-il ?

De nombreuses organisations utilisent des équipements qui inspectent le trafic chiffré à des fins de sécurité et de conformité. Pour lire le trafic TLS, ces équipements doivent le déchiffrer, ce qui implique de mettre fin à votre connexion, d’examiner le contenu et d’établir leur propre connexion pour la suite.

Pour que cela fonctionne sans que les navigateurs ne signalent d’erreur, l’entreprise installe son propre certificat racine sur les machines qu’elle gère. Les navigateurs et les applications système lui font confiance, donc tout semble normal. Le dispositif d’inspection effectue exactement l’interception que la vérification des certificats est censée détecter, et il a été autorisé à le faire.

Pourquoi curl signale tout de même un problème

curl peut ne pas utiliser le magasin de certificats de confiance du système, selon la manière dont il a été compilé et la bibliothèque TLS qu’il utilise. Ainsi, le certificat racine d’entreprise que votre navigateur accepte sans broncher est inconnu de curl, et curl signale à juste titre qu’il ne peut pas vérifier la chaîne de certificats.

La clé se trouve dans le journal détaillé : l’émetteur du certificat est votre propre organisation, ou le nom d’un fournisseur de sécurité, plutôt qu’une autorité de certification publique.

La solution correcte

Exportez le certificat racine de l’entreprise — votre équipe informatique peut vous le fournir, ou vous pouvez l’extraire d’un navigateur — et ajoutez-le en utilisant l’une des méthodes ci-dessus. CURL_CA_BUNDLE pour une session shell, le magasin système pour une machine que vous utilisez quotidiennement.

Cela permet de maintenir la vérification en état de fonctionnement. Vous faites confiance à une autorité supplémentaire que votre organisation a délibérément installée, plutôt que de tout accepter sans discernement.

La mauvaise solution

Activer « -k » (Tout autoriser) partout, de manière permanente. Cela fonctionne, mais cela signifie que vous ne remarqueriez pas une interception véritablement malveillante, car vous avez désactivé le seul mécanisme qui vous l’aurait signalée. Sur un réseau où des interceptions légitimes ont déjà lieu, la capacité à distinguer celles-ci des interceptions illégitimes est précisément ce qu’il convient de préserver.

Remarque sur les conteneurs

Les conteneurs n’héritent pas du magasin de confiance de l’hôte. Un conteneur qui fonctionne sur votre ordinateur portable mais qui échoue dans un environnement d’entreprise nécessite généralement que la racine de l’entreprise soit ajoutée à l’image ou montée dans celle-ci — ce qui constitue une solution à apporter au moment de la compilation, et non une raison de désactiver la vérification dans le Dockerfile.

Proxys et TLS

C'est notre domaine de compétence, et il s'agit surtout de savoir quel certificat fait l'objet de la plainte.

Deux vérifications distinctes

Lorsque vous acheminez curl via un proxy HTTPS, il y a deux connexions TLS et deux vérifications indépendantes.

Votre connexion au proxy. Contrôlée par les options --proxy-insecure, --proxy-cacert et les options associées.

La connexion à la destination. Contrôlée par les options -k, --cacert et les options habituelles.

Confondre ces deux connexions est une source fréquente de perte de temps. Si curl signale un problème de certificat alors qu’un proxy est configuré, déterminez laquelle des deux connexions a échoué avant de modifier quoi que ce soit — le mode de sortie détaillé permet de les distinguer.

Un proxy HTTP standard n’est pas à l’origine de ce problème

Avec un proxy HTTP standard et une destination HTTPS, curl envoie une requête CONNECT et le proxy ouvre un tunnel. La négociation TLS s’effectue alors de bout en bout entre vous et la destination, et le proxy ne peut ni voir ni modifier le certificat. Si vous rencontrez des erreurs de certificat via un tel proxy, la cause est l’une de celles mentionnées précédemment, et non le proxy lui-même.

C’est également la raison pour laquelle un proxy standard ne peut pas lire votre trafic HTTPS. Il achemine des octets chiffrés sans pouvoir les interpréter.

Ce qu’un proxy d’interception fait

Si un proxy est configuré pour inspecter le trafic HTTPS, il met fin à la connexion TLS et présente son propre certificat — il s’agit du cas d’inspection d’entreprise évoqué plus haut, sous une autre forme. La signature est la même : un émetteur inconnu dans la sortie détaillée.

La règle

Ajoutez l’autorité de certification du proxy plutôt que de désactiver la vérification. Même raisonnement que précédemment, et même effort.

Un point connexe qui importe davantage à nos clients que les certificats : vérifiez si vos recherches de noms d’hôte passent par le proxy ou sont résolues localement. Avec curl, socks5h:// envoie le nom d’hôte au proxy tandis que socks5:// le résout sur votre machine. Ce n’est pas un problème de certificat, mais c’est une autre façon dont une configuration de proxy agit souvent différemment de ce que son propriétaire avait prévu.

Dans le code plutôt qu'avec curl

On retrouve ce même choix dans tous les langages, généralement avec une ergonomie par défaut moins bonne.

Python

import requests

# Verification on, using a specific CA bundle — preferred
r = requests.get("https://internal.example.com", verify="/path/to/ca.crt")

# Verification off — equivalent to curl -k
r = requests.get("https://internal.example.com", verify=False)

requests émet un avertissement lorsque la vérification est désactivée, et une grande partie du code disponible sur Internet supprime cet avertissement plutôt que de le résoudre. Supprimer l’avertissement est nettement pire que le problème d’origine, car cela élimine le dernier signal indiquant qu’il y a quelque chose d’anormal.

requests respecte également REQUESTS_CA_BUNDLE , et SSL_CERT_FILE est largement pris en charge dans l’écosystème Python — ainsi, l’approche par variable d’environnement évoquée précédemment permet souvent de corriger d’un seul coup l’ensemble de la chaîne d’outils.

Node.js

// Preferred: supply the CA for this request
const https = require('https');
const fs = require('fs');
const agent = new https.Agent({ ca: fs.readFileSync('/path/to/ca.crt') });

// Avoid: disables verification for the entire process
// NODE_TLS_REJECT_UNAUTHORIZED=0

Cette variable d’environnement mérite une mise en garde spécifique. Elle s’applique à l’ensemble du processus, ce qui désactive la vérification pour chaque connexion établie par le processus, y compris celles que vous n’avez pas créées vous-même — dépendances, télémétrie, téléchargements de paquets. Node affiche lui-même un avertissement lorsqu’elle est définie. Utilisez plutôt NODE_EXTRA_CA_CERTS pour ajouter un certificat ; cela résout le problème réel sans effet collatéral.

Le modèle

Chaque écosystème propose à la fois une option ciblée et un commutateur global. L’option ciblée nécessite quelques caractères supplémentaires et maintient la vérification active pour tout ce que vous n’avez pas explicitement exclu.

Le commutateur global est celui qui se retrouve dans un dépôt, est copié dans trois autres services, et est découvert deux ans plus tard par quelqu’un qui tente de comprendre pourquoi une panne n’a pas été détectée.

Quand il est tout à fait acceptable de ne pas en tenir compte

Il ne s’agit pas d’une liste d’interdictions : il existe des cas réels où cela est justifié, et prétendre le contraire rendrait ces conseils faciles à ignorer.

Un serveur de développement local que vous avez vous-même démarré. Vous savez exactement ce qu’il y a à l’autre bout, car il se trouve sur votre propre machine. Une requête -k vers localhost ne présente pas de risque significatif. Fournir le certificat avec --cacert reste plus propre et ne prend que quelques secondes.

Un test interactif ponctuel où vous déboguez le certificat lui-même. Vérifier si le reste de la requête fonctionne pendant qu’un problème de certificat est en cours de résolution ailleurs est une utilisation tout à fait raisonnable.

Un réseau isolé que vous contrôlez de bout en bout, où aucun chemin ne permet à un intercepteur de s’interposer. Rare dans la pratique, et il vaut mieux être honnête avec soi-même pour savoir si c’est vraiment le cas.

Des tests automatisés sur une infrastructure de test éphémère avec des certificats auto-signés qui sont régénérés en permanence. Même dans ce cas, il est généralement possible et préférable de pointer vers le certificat.

Quand ce n’est pas acceptable

Tout ce qui se trouve en production. La documentation de curl elle-même le déconseille formellement, et à juste titre.

Tout ce qui envoie des identifiants. Sans vérification, vous ne pouvez pas savoir qui les reçoit.

Tout ce sur quoi vous agissez en fonction de la réponse. Sans vérification, la réponse aurait pu être rédigée par n’importe qui sur le chemin.

Tout ce qui se trouve sur un réseau que vous ne contrôlez pas — un Wi-Fi public, les bureaux d’un client, un environnement partagé.

Comme solution permanente à une erreur récurrente. Une erreur récurrente a une cause. Cette cause a une solution. L’-k, c’est une façon de ne pas la découvrir.

Le test en une ligne

Posez-vous la question suivante : si quelqu’un interceptait cette connexion en ce moment même, est-ce que je voudrais le savoir ?

Si oui, conservez la vérification et corrigez la cause sous-jacente. Si la réponse est sincèrement « non » — par exemple, s’il s’agit d’une requête sans importance adressée à une machine sur votre bureau — alors l’utilisation de -k convient parfaitement et cet article a été plus long que nécessaire.

Questions fréquentes

Comment ignorer les erreurs de certificat SSL dans curl ?

curl -k https://example.com, ou la version longue --insecure. Pour le certificat propre à un proxy HTTPS, la commande --proxy-insecure est distincte. La documentation de curl recommande vivement d’éviter cette pratique et de ne jamais l’utiliser en production.

Que fait réellement la commande curl -k ?

Cela désactive deux vérifications : celle visant à s’assurer que le certificat provient d’une autorité de certification de confiance, et celle visant à vérifier qu’il a bien été émis pour le nom d’hôte auquel vous vous êtes connecté. La connexion reste chiffrée mais n’est plus authentifiée, ce qui signifie qu’elle peut faire l’objet d’une interception que vous ne pourrez pas détecter.

Pourquoi curl renvoie-t-il une erreur de certificat alors que mon navigateur n’en signale pas ?

Généralement parce que le serveur n’envoie pas ses certificats intermédiaires. Les navigateurs récupèrent ou mettent souvent en cache automatiquement les certificats intermédiaires manquants ; ce n’est pas le cas de curl. Le serveur est mal configuré et le navigateur fait preuve de tolérance. Il se peut également que votre navigateur fasse confiance à un certificat racine d’entreprise que curl ne connaît pas.

Comment résoudre le message « impossible d’obtenir le certificat de l’émetteur local » ?

Dans l’ordre : demandez au serveur d’envoyer sa chaîne de certificats complète, mettez à jour le paquet de certificats d’autorité de certification (CA) de votre système, ou indiquez à curl le certificat correct à l’aide de --cacert. Dans les conteneurs, il s’agit très souvent simplement d’un paquet ca-certificates manquant.

Comment faire en sorte que curl fasse confiance à un certificat auto-signé ?

La vérification « curl --cacert /path/to/cert.crt https://internal.example.com. » reste activée et curl fait confiance à ce certificat spécifique pour cette connexion, ce qui est plus sûr et ne demande guère plus d’efforts que « -k ».

Puis-je définir un ensemble de certificats d’autorité de certification (CA) pour toutes les commandes curl ?

Oui. Définissez CURL_CA_BUNDLE sur le chemin d’accès de votre ensemble de certificats. curl prend également en charge SSL_CERT_FILE et SSL_CERT_DIR, que de nombreux autres outils respectent également, ce qui en fait un bon moyen de configurer tout un environnement en une seule fois.

La commande curl -k crypte-t-elle toujours mon trafic ?

Oui, la connexion reste cryptée. Cependant, le cryptage sans authentification ne protège que contre l’observation passive. Un intercepteur actif peut présenter n’importe quel certificat, tout décrypter et transmettre les données — ce que la vérification est justement censée empêcher.

Peut-on utiliser « curl -k » en toute sécurité dans un conteneur Docker ?

En général, cela n’est pas nécessaire. Les images de base minimales sont souvent fournies sans ensemble de certificats d’autorité de certification (CA) ; l’installation de « ca-certificates » permet donc de résoudre correctement ce problème. Si le problème provient d’un certificat racine d’entreprise, ajoutez-le à l’image ou montez-le plutôt que de désactiver la vérification.

Conclusion : la commande «

curl -k » s'exécute d'une simple frappe et fonctionne. Elle désactive simplement le mécanisme qui vous signalait un problème, mais le problème lui-même persiste.

Commencez par passer dix secondes sur curl -v. Les erreurs de certificat ont plusieurs causes, et chacune se manifeste clairement. L’absence d’un certificat intermédiaire est de loin la cause la plus courante, et cela explique ce cas déroutant où un site fonctionne dans un navigateur mais échoue avec curl : les navigateurs récupèrent les éléments manquants, contrairement à curl, et le serveur est bel et bien mal configuré. Dans les conteneurs, la solution réside très souvent simplement dans l’absence du paquet ca-certificates.

Lorsque vous devez faire confiance à quelque chose d’inhabituel, faites-le de manière spécifique. --cacert pour une connexion, CURL_CA_BUNDLE ou SSL_CERT_FILE pour un environnement, le magasin système pour une machine que vous utilisez quotidiennement. Chacune de ces méthodes permet de maintenir la vérification tout en indiquant à curl l’autorité supplémentaire que vous avez décidé d’accepter. Ces opérations prennent quelques secondes de plus que -k et échouent tout de même si un élément inattendu apparaît dans le chemin d’accès, ce qui est justement la raison d’être de cette vérification.

Sur les réseaux d’entreprise, la cause est généralement l’inspection TLS — et la solution consiste à ajouter le certificat racine de l’organisation plutôt qu’à désactiver la vérification. Sur un réseau pratiquant déjà une interception autorisée, la capacité à distinguer celle-ci d’une interception non autorisée revêt une importance encore plus grande que d’habitude, et non l’inverse.

Les proxys ne sont ici qu’une fausse piste. Un proxy HTTP ordinaire achemine le trafic HTTPS via un tunnel et ne peut pas intervenir sur le certificat ; si vous constatez des erreurs en passant par un proxy, la cause se trouve ailleurs. Nous vendons des proxys, mais nous n’avons rien à vous proposer pour résoudre ce problème.

Et si la réponse à la question « Est-ce que je voudrais savoir si quelqu’un interceptait cela en ce moment même ? » est « non » — s’il s’agit d’une requête sans importance adressée à un serveur sur votre propre bureau — alors « -k » convient parfaitement. C’est le réflexe, et non le drapeau, qui cause le préjudice.