Fix curl error 60: unable to get local issuer certificate

curl: (60) SSL certificate problem: unable to get local issuer certificate means curl could not build an acceptable certificate chain with its available trust information. The cause may be a missing local CA, a server that omits an intermediate certificate, or a corporate proxy whose CA is not trusted by this curl build.

Start with curl -V to identify the TLS backend, then curl -v https://example.com to inspect the failure and the CA paths it reports. Updating a trust store helps only if that is the store curl actually uses.

Repair the system CA package

If the CA package is missing, damaged, or stale, use the commands for your distribution:

# Debian / Ubuntu
sudo apt update && sudo apt install --reinstall ca-certificates
sudo update-ca-certificates

# RHEL / Fedora; older installations may use yum
sudo dnf reinstall ca-certificates
sudo update-ca-trust

# Arch Linux
sudo pacman -Syu ca-certificates

# For Homebrew installations that use this CA package
brew install ca-certificates

Schannel-based Windows builds normally use Windows trust. Other builds may use a file bundle. macOS builds also differ by backend and configuration; do not assume that every Homebrew curl uses the same trust source. curl documents the backend-specific behavior.

Supply a trusted CA bundle explicitly

A custom curl build or minimal container may not find the intended bundle:

# Download from a machine that already verifies HTTPS correctly.
# Do not use -k to obtain new trust roots.
curl -O https://curl.se/ca/cacert.pem
curl --cacert ./cacert.pem https://example.com

# For supported file-based backends, set a session-level bundle.
export CURL_CA_BUNDLE=/path/to/cacert.pem

CURL_CA_BUNDLE is not honored by the Schannel backend. Use the configuration supported by your build. For a corporate inspection proxy, obtain its CA through your administrator's trusted distribution channel. On Ubuntu, install a PEM-encoded CA certificate with a .crt suffix under /usr/local/share/ca-certificates/, then run sudo update-ca-certificates.

Check the chain served by the site

openssl s_client -connect example.com:443 -servername example.com \
  -showcerts -verify_hostname example.com -verify_return_error </dev/null

Read the diagnostics and the certificates the server sends. This uses OpenSSL's trust configuration, which may differ from curl's. If an intermediate certificate is missing, fix the server's chain: the leaf certificate comes first, followed by the required intermediates. A Let's Encrypt server configuration typically needs fullchain.pem, rather than the leaf-only cert.pem.

A browser may succeed because it has a cached intermediate or supports retrieval that another client does not. Browser success does not prove the server is sending a complete chain.

Check containers and CI images

Install CA certificates in package-manager-based images when absent:

# Alpine
RUN apk add --no-cache ca-certificates

# Debian slim
RUN apt-get update && apt-get install -y ca-certificates \
    && rm -rf /var/lib/apt/lists/*

Distroless images vary; some already include certificates and usually have no package manager. Inspect the actual image and its intended trust configuration.

What about curl -k?

curl -k https://example.com

This disables certificate verification. It can isolate a verification-related failure in a controlled test without credentials or sensitive data, but a successful response then proves nothing about the server's identity. Repair trust or the chain before using the request in an application or automation.

Common questions

Why does only Git fail?

Git's HTTPS transport uses libcurl, but its build and configuration may differ from the curl executable. Inspect http.sslBackend and http.sslCAInfo. To use an approved CA for one clone:

git -c http.sslCAInfo=/trusted/ca.pem clone https://example.com/repo.git

Do not turn off global http.sslVerify. See Git's HTTP configuration.

Why does the error appear only on the office network?

Compare proxy settings and the issuer of the certificate actually returned. A TLS inspection proxy can replace the site's certificate with one issued by the corporate CA; that CA must be trusted by the affected client.