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

curl 7.81 and later print "error setting certificate file: <path>" (or "error setting certificate path" for a CA directory); curl 7.74 and older printed "error setting certificate verify locations:" followed by the CAfile and CApath values. The path is whatever your configuration names.

curl (OpenSSL backend) — CURLE_SSL_CACERT_BADFILE

What it means

curl could not load the CA bundle it was told to use, so it refuses to make any HTTPS request at all. Nothing was sent to the server: the failure happens before the connection, while curl reads the file named after the colon. The path comes from --cacert, CURL_CA_BUNDLE, SSL_CERT_FILE, a .curlrc file or the default compiled into curl.

Why it happens

• A path from another distribution

  common

  Scripts, Dockerfiles and CI templates written for RHEL export CURL_CA_BUNDLE=/etc/pki/tls/certs/ca-bundle.crt; the same line on Debian, Ubuntu or Alpine names a file that does not exist there (and vice versa with /etc/ssl/certs/ca-certificates.crt).

• The image has no CA bundle installed

  common

  Minimal images often omit the ca-certificates package, so the default path compiled into curl points at nothing.

• The file exists but cannot be read

  occasional

  A bundle readable only by root, a broken symlink after an upgrade, or an empty file truncated by a failed copy all produce the same message.

• A relative path resolved from another directory

  occasional

  --cacert certs/ca.pem works in the project folder and fails when a cron job, systemd unit or CI step runs curl from a different working directory.

How to fix it

1. 1.

   Find where the path comes from

   Check the environment and ~/.curlrc for a CA setting, and curl -V for the TLS library: OpenSSL builds honour CURL_CA_BUNDLE and SSL_CERT_FILE, Schannel and Secure Transport builds use the system store unless told otherwise.

   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.

   Use the bundle path of this distribution, or none

   In most cases removing the override is the right fix: curl then uses the bundle path its package was built with. If you need a custom bundle, point at a file that exists on this system.

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

   Install the CA bundle package

   In slim and distroless-derived images, add ca-certificates at build time so the default path exists.

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

4. 4.

   Make the file readable and use an absolute path

   The account running curl needs read access to the bundle. Absolute paths keep working when the working directory changes.

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

← Browse the full signature error database