curl: (77) error setting certificate file: /etc/pki/tls/certs/ca-bundle.crt

curl 7.81 et les versions ultérieures affichent « error setting certificate file: <path> » (ou « error setting certificate path » pour un répertoire d’AC) ; curl 7.74 et les versions antérieures affichaient « error setting certificate verify locations: » suivi des valeurs CAfile et CApath. Le chemin est celui que désigne votre configuration.

curl (OpenSSL backend) — CURLE_SSL_CACERT_BADFILE

Ce que cela signifie

curl n’a pas pu charger le fichier d’AC qu’on lui a demandé d’utiliser, et refuse donc toute requête HTTPS. Rien n’a été envoyé au serveur : l’échec se produit avant la connexion, pendant que curl lit le fichier nommé après les deux-points. Le chemin provient de --cacert, de CURL_CA_BUNDLE, de SSL_CERT_FILE, d’un fichier .curlrc ou de la valeur par défaut compilée dans curl.

Pourquoi cela se produit

• Un chemin issu d’une autre distribution

  fréquente

  Les scripts, Dockerfiles et modèles de CI écrits pour RHEL exportent CURL_CA_BUNDLE=/etc/pki/tls/certs/ca-bundle.crt ; la même ligne sous Debian, Ubuntu ou Alpine désigne un fichier qui n’y existe pas (et inversement avec /etc/ssl/certs/ca-certificates.crt).

• Aucun fichier d’AC n’est installé dans l’image

  fréquente

  Les images minimales omettent souvent le paquet ca-certificates : le chemin par défaut compilé dans curl ne pointe alors vers rien.

• Le fichier existe mais ne peut pas être lu

  occasionnelle

  Un fichier d’AC lisible seulement par root, un lien symbolique cassé après une mise à niveau ou un fichier vide tronqué par une copie ratée produisent tous le même message.

• Un chemin relatif résolu depuis un autre répertoire

  occasionnelle

  --cacert certs/ca.pem fonctionne dans le dossier du projet et échoue lorsqu’une tâche cron, une unité systemd ou une étape de CI exécute curl depuis un autre répertoire de travail.

Comment corriger l’erreur

1. 1.

   Trouver d’où vient le chemin

   Cherchez un paramètre d’AC dans l’environnement et dans le fichier ~/.curlrc, et la bibliothèque TLS dans la sortie de curl -V : les builds OpenSSL tiennent compte de CURL_CA_BUNDLE et de SSL_CERT_FILE, tandis que les builds Schannel et Secure Transport utilisent le magasin du système sauf indication contraire.

   env | grep -E 'CURL_CA_BUNDLE|SSL_CERT_FILE|SSL_CERT_DIR'
   grep -sE 'cacert|capath' ~/.curlrc
   curl -V | head -1            # which TLS library this curl uses

2. 2.

   Utiliser le chemin du fichier d’AC de cette distribution, ou aucun

   Dans la plupart des cas, supprimer le remplacement est la bonne correction : curl utilise alors le chemin du fichier d’AC avec lequel son paquet a été compilé. Si vous avez besoin d’un fichier d’AC personnalisé, indiquez un fichier qui existe sur ce système.

   # Debian, Ubuntu, Alpine:        /etc/ssl/certs/ca-certificates.crt
   # RHEL, Fedora, Amazon Linux:    /etc/pki/tls/certs/ca-bundle.crt
   # openSUSE:                      /etc/ssl/ca-bundle.pem
   unset CURL_CA_BUNDLE        # let curl use the bundle it was built with
   ls -l /etc/ssl/certs/ca-certificates.crt

3. 3.

   Installer le paquet du fichier d’AC

   Dans les images slim et dérivées de distroless, ajoutez ca-certificates au moment du build pour que le chemin par défaut existe.

   apt-get install -y ca-certificates     # Debian/Ubuntu
   apk add --no-cache ca-certificates     # Alpine
   dnf install -y ca-certificates         # RHEL/Fedora

4. 4.

   Rendre le fichier lisible et utiliser un chemin absolu

   Le compte qui exécute curl doit avoir accès en lecture au fichier d’AC. Les chemins absolus continuent de fonctionner quand le répertoire de travail change.

   ls -l /opt/certs/bundle.pem
   sudo chmod 0644 /opt/certs/bundle.pem
   curl --cacert "$(realpath /opt/certs/bundle.pem)" https://api.example.com/

← Parcourir toute la base de données des erreurs de signature