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

-kSSL/TLS

Autoriser les connexions non sécurisées — ignorer toute vérification SSL

--cacertSSL/TLS

Vérifier le certificat du serveur contre un bundle CA spécifique

--certSSL/TLS

Fournir un certificat client pour l'authentification TLS mutuelle

--keySSL/TLS

Fournir le fichier de clé privée pour le certificat client

--tlsv1.2SSL/TLS

Utiliser la version TLS 1.2 ou supérieure pour la connexion

--tlsv1.3SSL/TLS

Utiliser la version TLS 1.3 ou supérieure pour la connexion

--ssl-reqdSSL/TLS

Exiger SSL/TLS pour la connexion (échouer si non disponible)

--ciphersSSL/TLS

Spécifier quels chiffrements SSL utiliser pour la connexion

--cert-typeSSL/TLS

Spécifier le type de certificat client (PEM, DER, ENG, P12)

--pinnedpubkeySSL/TLS

Épingler et vérifier la clé publique du serveur (style HPKP)

-xProxy

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

--socks5-hostnameProxy

Proxy SOCKS5 avec résolution DNS via le proxy

--proxy-cacertProxy

Certificat CA pour vérifier le proxy HTTPS lui-même

--resolveRéseau

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

--local-portRéseau

Définir le numéro ou la plage de port local pour la connexion

--interfaceRéseau

Lier la connexion à une interface réseau spécifique

--dns-serversRéseau

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 --cacert avec le certificat CA réel — c'est à la fois plus sûr et plus explicite.
$ curl -k https://localhost:8443/api/health

N'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 --cacert indique à 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/data

curl --cert : Certificat client (TLS mutuel)

Fonctionnement
L'option --cert fournit 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 --key sauf si la clé est intégrée au fichier certificat.
$ curl --cert client.pem --key client-key.pem https://mtls-api.example.com/secure

curl --key : Clé privée du certificat client

Fonctionnement
L'option --key spé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/secure

curl --tlsv1.2 : Forcer TLS 1.2 minimum

Fonctionnement
L'option --tlsv1.2 force 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.3 force 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/data

Options SSL/TLS supplémentaires

--ssl-reqd

Exiger SSL/TLS pour la connexion (échouer si non disponible)

--ciphers

Spécifier quels chiffrements SSL utiliser pour la connexion

--cert-type

Spécifier le type de certificat client (PEM, DER, ENG, P12)

--pinnedpubkey

É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/data

curl --socks5 : Utiliser un proxy SOCKS5

Fonctionnement
L'option --socks5 indique à 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-hostname pour 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/data

curl --proxy-user : Authentification proxy

Fonctionnement
L'option --proxy-user (ou -U) envoie les identifiants d'authentification au serveur proxy. Le format est user: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/data

curl --noproxy : Contourner le proxy pour certains hôtes

Fonctionnement
L'option --noproxy spé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.com correspond à 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/api

Options proxy supplémentaires

--socks5-hostname

Proxy SOCKS5 avec résolution DNS via le proxy

--proxy-cacert

Certificat CA pour vérifier le proxy HTTPS lui-même

curl --resolve : Résolution DNS personnalisée

Fonctionnement
L'option --resolve fournit une adresse IP personnalisée pour une paire host:port spécifique, contournant complètement la recherche DNS. Le format est host:port:address. Plusieurs entrées --resolve peuvent ê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/health

curl --connect-to : Rediriger la connexion vers un autre hôte

Fonctionnement
L'option --connect-to redirige la connexion TCP vers une paire host:port différente tout en conservant l'URL originale pour la requête HTTP (y compris l'en-tête Host et 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/health

Options réseau supplémentaires

--local-port

Définir le numéro ou la plage de port local pour la connexion

--interface

Lier la connexion à une interface réseau spécifique

--dns-servers

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/status

TLS 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/data

Proxy 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/data

Conteneur 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/health

Proxy 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/status

Questions 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.