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

curl 7.81 y posteriores imprimen «error setting certificate file: <path>» (o «error setting certificate path» para un directorio de CA); curl 7.74 y anteriores imprimían «error setting certificate verify locations:» seguido de los valores de CAfile y CApath. La ruta es la que indique tu configuración.

curl (OpenSSL backend) — CURLE_SSL_CACERT_BADFILE

Qué significa

curl no pudo cargar el bundle de CA que se le indicó, así que se niega a hacer ninguna solicitud HTTPS. No se envió nada al servidor: el fallo ocurre antes de la conexión, mientras curl lee el archivo que aparece después de los dos puntos. La ruta procede de --cacert, CURL_CA_BUNDLE, SSL_CERT_FILE, un archivo .curlrc o el valor predeterminado compilado en curl.

Por qué ocurre

• Una ruta de otra distribución

  frecuente

  Los scripts, Dockerfiles y plantillas de CI escritos para RHEL exportan CURL_CA_BUNDLE=/etc/pki/tls/certs/ca-bundle.crt; la misma línea en Debian, Ubuntu o Alpine apunta a un archivo que allí no existe (y al revés con /etc/ssl/certs/ca-certificates.crt).

• La imagen no tiene instalado ningún bundle de CA

  frecuente

  Las imágenes mínimas suelen omitir el paquete ca-certificates, así que la ruta predeterminada compilada en curl no apunta a nada.

• El archivo existe, pero no se puede leer

  ocasional

  Un bundle que solo puede leer root, un enlace simbólico roto tras una actualización o un archivo vacío truncado por una copia fallida producen el mismo mensaje.

• Una ruta relativa resuelta desde otro directorio

  ocasional

  --cacert certs/ca.pem funciona en la carpeta del proyecto y falla cuando un trabajo de cron, una unidad de systemd o un paso de CI ejecuta curl desde otro directorio de trabajo.

Cómo solucionarlo

1. 1.

   Averiguar de dónde viene la ruta

   Busca un ajuste de CA en el entorno y en ~/.curlrc, y consulta la biblioteca TLS con curl -V: las compilaciones con OpenSSL respetan CURL_CA_BUNDLE y SSL_CERT_FILE, y las compilaciones con Schannel y Secure Transport usan el almacén del sistema salvo que se les indique otra cosa.

   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.

   Usar la ruta del bundle de esta distribución, o ninguna

   En la mayoría de los casos, la solución correcta es quitar el ajuste que sustituye la ruta predeterminada: curl usa entonces la ruta del bundle con la que se compiló su paquete. Si necesitas un bundle personalizado, apunta a un archivo que exista en este sistema.

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

   Instalar el paquete del bundle de CA

   En las imágenes slim y en las derivadas de distroless, añade ca-certificates al construir la imagen para que exista la ruta predeterminada.

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

4. 4.

   Hacer legible el archivo y usar una ruta absoluta

   La cuenta que ejecuta curl necesita permiso de lectura sobre el bundle. Las rutas absolutas siguen funcionando aunque cambie el directorio de trabajo.

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

← Explorar toda la base de datos de errores de firma