curl: (77) Problem With the SSL CA Cert: How to Fix It

Exit code 77 is libcurl's CURLE_SSL_CACERT_BADFILE, documented as "Problem with reading the SSL CA cert (path? access rights?)". curl could not load the CA bundle it was told to use, so it stopped before it could verify any server. The failure is entirely local: the file named by --cacert, CURL_CA_BUNDLE, SSL_CERT_FILE, PHP's curl.cainfo, Git's http.sslCAInfo or the compiled-in default path is missing, unreadable, empty or not a PEM certificate file.

Depending on the curl and TLS library version the message reads either error setting certificate file: /path/ca.pem (current curl with OpenSSL) or error setting certificate verify locations: CAfile: ... CApath: ... (older builds). It is not a problem with the remote site's certificate. That case is error 60, SSL certificate problem: unable to get local issuer certificate, which you get when the bundle loads but does not contain the issuer.

In a test with curl 8.12 on OpenSSL 3.5, a nonexistent path, a file without read permission, an empty file and a non-PEM file all end in exit code 77, while a valid PEM file that simply lacks the right CA gives exit code 60.

On Debian and Ubuntu, libcurl4 only recommends ca-certificates, so apt-get install --no-install-recommends curl can produce a working curl binary with no bundle at the default path. Current Alpine base images already ship the bundle (ca-certificates-bundle).

Browsers never show this error. Chrome, Edge, Firefox and Safari use their own or the operating system's root store, so a site that opens in the browser can still fail with curl 77 on the same machine.

A CDN, reverse proxy or load balancer cannot cause error 77: curl fails while loading a local file, before it talks to any server. The one proxy-related check is a TLS-inspection setup where --cacert, CURL_CA_BUNDLE or http.sslCAInfo points at the company root certificate; if that file is moved or missing on some machines, every client using the setting fails with 77.

Here "the site" is the machine or container running curl, PHP or Git.

1. Find which file the client tries to load.

   env | grep -E 'CURL_CA_BUNDLE|SSL_CERT_FILE|SSL_CERT_DIR'
   git config --show-origin --get-all http.sslCAInfo
   php -i | grep -E 'curl.cainfo|openssl.cafile'
   curl -v https://example.com -o /dev/null 2>&1 | grep -E 'CAfile|CApath' 

   With a working default, curl -v prints lines such as CAfile: /etc/pki/tls/certs/ca-bundle.crt.
2. Check the file itself.

   ls -l /path/to/ca.pem
   grep -c 'BEGIN CERTIFICATE' /path/to/ca.pem
   openssl x509 -in /path/to/ca.pem -noout -subject

   It must exist, be readable by the user running the client (for example www-data for PHP-FPM) and contain PEM certificates.
3. Install or restore the system bundle.

   # Debian / Ubuntu  -> /etc/ssl/certs/ca-certificates.crt
   apt-get update && apt-get install -y ca-certificates
   # RHEL / Fedora     -> /etc/pki/tls/certs/ca-bundle.crt
   dnf install -y ca-certificates
   # Alpine
   apk add --no-cache ca-certificates
   # FROM scratch: copy the bundle from a build stage
   COPY --from=build /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/

4. Add a private CA the supported way instead of a custom path: on Debian copy it to /usr/local/share/ca-certificates/ (with a .crt extension) and run update-ca-certificates; on RHEL copy it to /etc/pki/ca-trust/source/anchors/ and run update-ca-trust.
5. Remove stale overrides: unset CURL_CA_BUNDLE, git config --global --unset http.sslCAInfo, or fix curl.cainfo and restart PHP-FPM.

Do not "fix" 77 with -k, CURLOPT_SSL_VERIFYPEER = false or http.sslVerify=false. That disables certificate verification for every request and leaves the real misconfiguration in place.

If you see "cURL error 77" inside an application (a CMS plugin, a package manager, a deploy tool), the cause is on the server or computer running that application, not on the website it is calling and not in your browser.

• On your own computer, follow the steps above: check environment variables, Git config and the CA bundle package.
• On shared hosting, send the exact message, including the file path, to the hosting provider; only they can fix the PHP or system CA configuration.
• Switching network, VPN, DNS or browser changes nothing, because the error happens before any connection is validated.

curl -sS -o /dev/null -w '%{http_code}\n' https://example.com; echo "exit=$?"
GIT_CURL_VERBOSE=1 git ls-remote https://github.com/git/git.git HEAD

Exit code 0 and an HTTP status mean the bundle loads. If the next failure is error 60, the bundle works but the server's chain is incomplete or untrusted; check the server with the enterno.io SSL checker.

• Python SSL: CERTIFICATE_VERIFY_FAILED
• Java PKIX path building failed
• SEC_ERROR_UNKNOWN_ISSUER: issuer not in the trust store
• Incomplete certificate chain: the usual cause of curl 60
• TLS works in the browser but fails in a client