Guide de configuration SSL, TLS et proxy pour curl
La configuration des certificats HTTPS, des versions TLS, des proxies et de la résolution DNS personnalisée dans curl est essentielle pour la communication sécurisée des API, les pipelines CI/CD et le débogage des problèmes réseau. Ce guide couvre toutes les options SSL, TLS, proxy et réseau — de la désactivation des vérifications de certificat avec -k pour le développement local à la mise en place du TLS mutuel avec --cert et le routage du trafic via des proxies SOCKS5. Chaque option inclut une explication claire, des considérations de sécurité et un exemple prêt à copier.
Référence rapide des options SSL et proxy
Autoriser les connexions non sécurisées — ignorer toute vérification SSL
Vérifier le certificat du serveur contre un bundle CA spécifique
Fournir un certificat client pour l'authentification TLS mutuelle
Fournir le fichier de clé privée pour le certificat client
Utiliser la version TLS 1.2 ou supérieure pour la connexion
Utiliser la version TLS 1.3 ou supérieure pour la connexion
Exiger SSL/TLS pour la connexion (échouer si non disponible)
Spécifier quels chiffrements SSL utiliser pour la connexion
Spécifier le type de certificat client (PEM, DER, ENG, P12)
Épingler et vérifier la clé publique du serveur (style HPKP)
Router tout le trafic via le serveur proxy spécifié
Router la connexion via un proxy SOCKS5
Fournir nom_utilisateur:mot_de_passe pour le serveur proxy
Liste des hôtes qui ne doivent pas passer par le proxy
Proxy SOCKS5 avec résolution DNS via le proxy
Certificat CA pour vérifier le proxy HTTPS lui-même
Associer une paire host:port spécifique à une adresse IP personnalisée
Se connecter à un host:port différent de celui spécifié par l'URL
Définir le numéro ou la plage de port local pour la connexion
Lier la connexion à une interface réseau spécifique
Utiliser des serveurs DNS personnalisés au lieu des valeurs système par défaut (c-ares)
curl -k : Ignorer les erreurs de certificat SSL
- Fonctionnement
- L'option
-k(ou--insecure) désactive toute vérification de certificat SSL/TLS. curl ne vérifiera pas si le certificat du serveur est signé par une CA de confiance, si le nom d'hôte correspond, ou si le certificat a expiré. - Quand utiliser
- À utiliser uniquement pour le développement local avec des certificats auto-signés ou des environnements de test. Pour le staging/la production, utilisez plutôt
--cacertavec le certificat CA réel — c'est à la fois plus sûr et plus explicite.
$ curl -k https://localhost:8443/api/healthN'utilisez jamais -k dans les scripts de production ou les pipelines CI/CD. Cela désactive toute validation de certificat, rendant votre connexion vulnérable aux attaques man-in-the-middle. Utilisez --cacert pour faire confiance à une CA spécifique.
curl --cacert : Utiliser un certificat CA personnalisé
- Fonctionnement
- L'option
--cacertindique à curl de vérifier le certificat SSL du serveur contre un fichier de bundle CA (Certificate Authority) spécifique au format PEM, au lieu du magasin de confiance par défaut du système. - Quand utiliser
- À utiliser lorsque votre serveur utilise un certificat signé par une CA privée ou interne absente du magasin de confiance système. C'est courant dans les environnements d'entreprise, les clusters Kubernetes et les configurations Docker avec PKI interne.
$ curl --cacert /path/to/corporate-ca.pem https://internal-api.example.com/datacurl --cert : Certificat client (TLS mutuel)
- Fonctionnement
- L'option
--certfournit un certificat côté client pour le TLS mutuel (mTLS). En mTLS, le serveur et le client présentent tous deux des certificats pour vérifier l'identité de l'autre. Le fichier certificat doit être au format PEM ou PKCS#12. - Quand utiliser
- Requis lorsque le serveur exige l'authentification par certificat client — courant dans les API bancaires, les services gouvernementaux, la communication IoT et les architectures zero-trust. Toujours associer avec
--keysauf si la clé est intégrée au fichier certificat.
$ curl --cert client.pem --key client-key.pem https://mtls-api.example.com/securecurl --key : Clé privée du certificat client
- Fonctionnement
- L'option
--keyspécifie le fichier de clé privée associé au certificat client fourni par--cert. La clé doit correspondre au certificat. Si la clé est protégée par mot de passe, curl demandera la phrase de passe (ou utilisez--pass). - Quand utiliser
- Toujours utiliser avec
--cert. Si la clé privée est déjà intégrée dans le fichier certificat (courant avec les fichiers PKCS#12 / .p12), vous pouvez omettre--key.
$ curl --cert client.pem --key client-key.pem --cacert server-ca.pem https://api.example.com/securecurl --tlsv1.2 : Forcer TLS 1.2 minimum
- Fonctionnement
- L'option
--tlsv1.2force curl à utiliser TLS 1.2 comme version minimale acceptable pour la négociation SSL/TLS. Les protocoles plus anciens (TLS 1.0, 1.1, SSLv3) sont rejetés. - Quand utiliser
- À utiliser pour imposer un standard de sécurité minimum. TLS 1.2 est requis pour la conformité PCI-DSS et est supporté par tous les serveurs modernes. La plupart des builds curl modernes utilisent déjà TLS 1.2+ par défaut, mais cette option le rend explicite.
$ curl --tlsv1.2 -v https://secure.example.com/api 2>&1 | grep 'SSL connection'curl --tlsv1.3 : Forcer TLS 1.3 minimum
- Fonctionnement
- L'option
--tlsv1.3force curl à utiliser TLS 1.3 — la version TLS la plus rapide et la plus sécurisée. TLS 1.3 élimine l'aller-retour supplémentaire dans la négociation (support 0-RTT) et supprime toutes les suites de chiffrement obsolètes. - Quand utiliser
- À utiliser lorsque vous savez que le serveur supporte TLS 1.3 et que vous voulez les meilleures performances et sécurité. Note : TLS 1.3 nécessite OpenSSL 1.1.1+ ou une bibliothèque TLS compatible. Tous les serveurs ne le supportent pas encore.
$ curl --tlsv1.3 https://modern-api.example.com/dataOptions SSL/TLS supplémentaires
Exiger SSL/TLS pour la connexion (échouer si non disponible)
Spécifier quels chiffrements SSL utiliser pour la connexion
Spécifier le type de certificat client (PEM, DER, ENG, P12)
Épingler et vérifier la clé publique du serveur (style HPKP)
curl -x : Utiliser un proxy HTTP/HTTPS
- Fonctionnement
- L'option
-x(ou--proxy) route tout le trafic curl via le serveur proxy spécifié. Le format est[protocol://]host[:port]. Protocoles proxy supportés : HTTP, HTTPS, SOCKS4, SOCKS5. - Quand utiliser
- À utiliser pour les serveurs proxy d'entreprise, le débogage avec des outils comme Fiddler, Charles ou mitmproxy, le test de restrictions géographiques, ou lorsque l'accès Internet direct n'est pas disponible. Vous pouvez aussi définir les variables d'environnement
http_proxy/https_proxy.
$ curl -x http://proxy.example.com:8080 https://api.example.com/datacurl --socks5 : Utiliser un proxy SOCKS5
- Fonctionnement
- L'option
--socks5indique à curl d'utiliser un proxy SOCKS5 pour la connexion TCP. Contrairement aux proxies HTTP, SOCKS5 opère au niveau TCP et peut gérer n'importe quel protocole — pas seulement HTTP. La résolution DNS est faite localement par défaut ; utilisez--socks5-hostnamepour résoudre le DNS via le proxy. - Quand utiliser
- À utiliser pour les tunnels SSH (
ssh -D), l'accès au réseau Tor, ou lorsque le proxy doit gérer des protocoles non-HTTP. SOCKS5 supporte UDP et peut optionnellement gérer le DNS — le rendant plus flexible que les proxies HTTP.
$ curl --socks5 localhost:1080 https://api.example.com/datacurl --proxy-user : Authentification proxy
- Fonctionnement
- L'option
--proxy-user(ou-U) envoie les identifiants d'authentification au serveur proxy. Le format estuser:password. C'est séparé de l'authentification serveur (-u). - Quand utiliser
- Requis lorsque le serveur proxy exige une authentification — courant dans les environnements réseau d'entreprise. Les identifiants sont envoyés au proxy, pas au serveur cible.
$ curl -x http://proxy.corp.com:3128 -U user:pass https://external-api.com/datacurl --noproxy : Contourner le proxy pour certains hôtes
- Fonctionnement
- L'option
--noproxyspécifie une liste séparée par des virgules d'hôtes, domaines ou adresses IP qui doivent contourner le proxy et se connecter directement. Supporte les jokers :*.example.comcorrespond à tous les sous-domaines. - Quand utiliser
- À utiliser pour exclure localhost, les services internes ou des domaines spécifiques du proxy. C'est important lorsqu'un proxy est configuré globalement via des variables d'environnement mais que certains hôtes (comme les services locaux) nécessitent un accès direct. Utilisez
*pour contourner le proxy pour tous les hôtes.
$ curl -x http://proxy:8080 --noproxy "localhost,127.0.0.1,*.internal.com" https://localhost:3000/apiOptions proxy supplémentaires
Proxy SOCKS5 avec résolution DNS via le proxy
Certificat CA pour vérifier le proxy HTTPS lui-même
curl --resolve : Résolution DNS personnalisée
- Fonctionnement
- L'option
--resolvefournit une adresse IP personnalisée pour une pairehost:portspécifique, contournant complètement la recherche DNS. Le format esthost:port:address. Plusieurs entrées--resolvepeuvent être fournies. - Quand utiliser
- Essentiel pour tester avant la propagation DNS, vérifier un backend spécifique derrière un load balancer, ou le développement local nécessitant un vrai nom d'hôte pour la validation du certificat SSL. Contrairement à la modification de
/etc/hosts, c'est par requête et spécifique au port.
$ curl --resolve api.example.com:443:127.0.0.1 https://api.example.com/healthcurl --connect-to : Rediriger la connexion vers un autre hôte
- Fonctionnement
- L'option
--connect-toredirige la connexion TCP vers une pairehost:portdifférente tout en conservant l'URL originale pour la requête HTTP (y compris l'en-têteHostet le SNI). Format :HOST1:PORT1:HOST2:PORT2. - Quand utiliser
- À utiliser pour tester un serveur backend spécifique derrière un load balancer sans modifier le DNS ou
/etc/hosts. Contrairement à--resolve, cela mappe host:port vers host:port (pas vers une IP), ce qui est utile lorsque la cible a aussi un nom d'hôte.
$ curl --connect-to api.example.com:443:backend1.internal:8443 https://api.example.com/healthOptions réseau supplémentaires
Définir le numéro ou la plage de port local pour la connexion
Lier la connexion à une interface réseau spécifique
Utiliser des serveurs DNS personnalisés au lieu des valeurs système par défaut (c-ares)
Scénarios réels SSL et proxy
Ces exemples combinent plusieurs options pour gérer les tâches courantes de sécurité et de réseau dans les environnements de développement, CI/CD et production.
Tester HTTPS sur localhost
Lors du développement local avec un certificat auto-signé, combinez --resolve avec --cacert (ou -k pour un test rapide). Cela vous permet d'utiliser un vrai nom d'hôte pour un SSL/SNI correct sans modifier votre fichier hosts.
$ curl --resolve myapp.local:443:127.0.0.1 --cacert local-ca.pem https://myapp.local/api/statusTLS mutuel (authentification par certificat client)
Certaines API exigent que le serveur et le client présentent des certificats. Fournissez --cert, --key et --cacert pour établir une connexion TLS bidirectionnelle entièrement vérifiée.
$ curl --cert client.pem --key client-key.pem --cacert server-ca.pem https://mtls-api.example.com/dataProxy d'entreprise avec authentification
Dans les réseaux d'entreprise avec des serveurs proxy obligatoires, combinez -x avec -U pour les identifiants proxy. Ajoutez --noproxy pour exclure les services internes du proxy.
$ curl -x http://proxy.corp.com:3128 -U user:pass --noproxy "*.internal.corp" https://external-api.com/dataConteneur Docker avec CA interne
Lorsque les services Docker utilisent des certificats d'une CA interne, montez le certificat CA dans le conteneur et référencez-le avec --cacert. C'est plus sûr que -k car cela valide toujours la chaîne de certificats.
$ curl --cacert /etc/ssl/certs/internal-ca.crt https://service.docker.internal:8443/healthProxy SOCKS5 via tunnel SSH
Créez un proxy SOCKS5 avec ssh -D et routez le trafic curl à travers avec --socks5. C'est utile pour accéder aux services internes via un hôte bastion.
$ curl --socks5 localhost:1080 https://internal-api.example.com/statusQuestions fréquentes sur SSL et proxy dans curl
Comment ignorer la vérification du certificat SSL dans curl ?
Utilisez curl -k URL ou curl --insecure URL. Cela désactive toutes les vérifications de certificat — expiration, non-correspondance du nom d'hôte, CA non approuvée. À utiliser uniquement pour le développement local. En production, utilisez --cacert avec le certificat CA réel.
Comment faire confiance à un certificat auto-signé avec curl ?
Utilisez curl --cacert /path/to/ca.pem URL pour spécifier le certificat CA qui a signé votre certificat auto-signé. C'est plus sûr que -k car cela valide toujours la chaîne de certificats — en ne faisant confiance qu'à votre CA spécifique.
Comment vérifier quelle version TLS curl utilise ?
Exécutez curl -v URL et cherchez la ligne * SSL connection using TLSv1.x / CipherSuite dans la sortie détaillée. Pour forcer une version spécifique, utilisez --tlsv1.2 ou --tlsv1.3.
Qu'est-ce que le TLS mutuel (mTLS) et comment l'utiliser avec curl ?
Le TLS mutuel exige que le serveur et le client présentent des certificats. Utilisez : curl --cert client.pem --key client-key.pem --cacert server-ca.pem URL. La paire --cert/--key authentifie le client ; --cacert vérifie le serveur.
Comment utiliser curl via un proxy HTTP ?
Utilisez curl -x http://proxy:port URL. Pour un proxy HTTPS : curl -x https://proxy:port URL. Alternativement, définissez les variables d'environnement http_proxy et https_proxy — curl les détecte automatiquement.
Comment utiliser curl avec un proxy SOCKS5 ?
Utilisez curl --socks5 host:port URL pour la résolution DNS locale, ou curl --socks5-hostname host:port URL pour résoudre le DNS via le proxy (important pour la confidentialité/Tor). Exemple avec tunnel SSH : ssh -D 1080 user@bastion, puis curl --socks5 localhost:1080 URL.
Comment s'authentifier auprès d'un serveur proxy dans curl ?
Utilisez curl -x http://proxy:port -U user:password URL. L'option -U (ou --proxy-user) envoie les identifiants au proxy. C'est séparé de -u, qui s'authentifie auprès du serveur cible.
Comment exclure certains hôtes du proxy dans curl ?
Utilisez --noproxy "localhost,127.0.0.1,*.internal.com" ou définissez la variable d'environnement NO_PROXY. Supporte les jokers (*.example.com). Utilisez --noproxy "*" pour contourner entièrement le proxy pour une seule requête.
Comment tester HTTPS sur localhost avec curl ?
Pour un test rapide : curl -k https://localhost:8443/. Pour une validation correcte : curl --resolve myapp.local:443:127.0.0.1 --cacert local-ca.pem https://myapp.local/. L'approche --resolve permet la correspondance correcte du nom d'hôte du certificat.
Comment remplacer la résolution DNS pour un hôte spécifique dans curl ?
Utilisez curl --resolve host:port:IP URL. Exemple : curl --resolve api.example.com:443:192.168.1.100 https://api.example.com/. Cela contourne le DNS uniquement pour cette paire host:port — pas besoin de modifier /etc/hosts.
Comment corriger l'erreur 'SSL certificate problem: certificate has expired' dans curl ?
Le certificat du serveur a expiré. Solutions : (1) Renouveler le certificat sur le serveur, (2) Mettre à jour votre bundle CA : curl --cacert /path/to/updated-ca.pem URL, (3) Pour test uniquement : curl -k URL. Vérifier l'expiration : curl -v URL 2>&1 | grep expire.
Est-il sûr d'utiliser curl --insecure (-k) en production ?
Non. L'option -k désactive toute validation de certificat — expiration, nom d'hôte et chaîne de confiance. Cela rend votre connexion vulnérable aux attaques man-in-the-middle. Utilisez toujours --cacert avec le certificat CA spécifique en production et dans les pipelines CI/CD.