curl: (60) SSL certificate problem: unable to get local issuer certificate

Hi, it's BlueByte. A curl https://… that works from your laptop fails on a build agent, inside a container, or on the office network with curl: (60) SSL certificate problem: unable to get local issuer certificate. The server is up — a browser opens the same URL without a warning — but curl refuses the handshake. We'll walk through what the message means, the four places the missing issuer can hide, the two commands that tell them apart, the fix for each, and how to keep the next runner from failing the same way.

What "local issuer" means, and the four messages that share exit code 60

Before curl transfers a byte over TLS it checks, in the manual's words, that the certificate contains the right name which matches the hostname in the URL, and that it has been signed by a CA certificate present in the cert store — the trusted roots curl was built with or told to use. Error 60 is the second check failing; the suffix comes from the TLS backend (OpenSSL on most Linux builds) and says which link broke:

curl: (60) SSL certificate problem: unable to get local issuer certificate
curl: (60) SSL certificate problem: self-signed certificate in certificate chain
curl: (60) SSL certificate problem: self-signed certificate
curl: (60) SSL certificate problem: certificate has expired

"unable to get local issuer certificate" means curl walked the chain the server sent, reached a certificate whose issuer it could not find in its store, and stopped. All four exit with status 60 — Peer certificate cannot be authenticated with known CA certificates — so only the text tells them apart.

Four places the issuer goes missing

The server sends an incomplete chain. A site certificate is signed by an intermediate CA, which is signed by a root in your store. The server is supposed to send the intermediate too; if it sends only the leaf, curl cannot bridge leaf to root. Browsers hide this mistake by fetching the missing intermediate themselves; curl and OpenSSL do not. "Works in Chrome, fails in curl" is the classic sign.

A TLS-inspecting proxy re-signs the site. Firewalls that decrypt HTTPS present a certificate issued by the company's own CA. Managed laptops trust it because IT pushed that CA into the OS store; curl in a container, a CI runner or a fresh VM has never seen it.

curl is reading a different store than you think. CURL_CA_BUNDLE, SSL_CERT_FILE or SSL_CERT_DIR point at a file that lacks the root; a curl from conda, Git for Windows or a vendored toolchain ships its own bundle; on Windows, curl.exe also picks up any curl-ca-bundle.crt next to the binary, in the working directory or along %PATH%.

The store is old. A base image or long-lived VM whose ca-certificates package predates the root the site now chains to. Same message, no proxy involved.

Two commands that tell the causes apart

First, ask curl which store it used. With -v, the OpenSSL backend prints the file and directory right before the failure:

curl -v https://incomplete-chain.badssl.com/ -o /dev/null 2>&1 | grep -E 'CAfile|CApath|certificate problem'

*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* SSL certificate problem: unable to get local issuer certificate

If CAfile is not the path you expected, jump to Fix 3. Otherwise look at what the server actually sent:

echo | openssl s_client -connect incomplete-chain.badssl.com:443 -servername incomplete-chain.badssl.com 2>/dev/null | grep -E '^ *[0-9]+ s:|^ *i:|Verify return code'

 0 s:CN = *.badssl.com
   i:C = US, O = Let's Encrypt, CN = …
    Verify return code: 21 (unable to verify the first certificate)

One certificate at depth 0 and nothing at depth 1 means the intermediate is missing — cause one. An issuer naming your company instead of a public CA means a proxy re-signed it — cause two. A complete public chain that still fails means the root is not in the store curl is reading — cause three or four.

Fix 1: the server sends only the leaf

The real fix is on the server: serve the file that includes the intermediates (fullchain.pem from certbot, or the bundle your CA ships) and reload. If you do not own the server and need the transfer today, fetch the missing issuer from the URL in the leaf's Authority Information Access extension, append it to a copy of your bundle, and pass that with --cacert:

HOST=incomplete-chain.badssl.com
echo | openssl s_client -connect "$HOST:443" -servername "$HOST" 2>/dev/null | openssl x509 -outform PEM > leaf.pem
AIA=$(openssl x509 -in leaf.pem -noout -ext authorityInfoAccess | grep -oE 'http[^ ]+' | grep -vi ocsp | head -1)
curl -sS "$AIA" | openssl x509 -inform DER -out issuer.pem
cat /etc/ssl/certs/ca-certificates.crt issuer.pem > bundle.pem
curl -sS --cacert bundle.pem "https://$HOST/" -o /dev/null -w '%{http_code} %{ssl_verify_result}\n'

200 0

The issuer is still checked against the root in your store — you only supplied the link the server forgot. Most CAs publish it in DER form; if openssl x509 complains, drop -inform DER. Keep the bundle scoped to that host and file the server-side fix.

Fix 2: trust the inspecting proxy's CA where curl looks

Get the CA certificate from IT, add it to the OS trust source the default bundle is built from, and rebuild:

# Debian / Ubuntu — the file must end in .crt
sudo cp corp-root-ca.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates
# RHEL / Fedora / Amazon Linux
sudo cp corp-root-ca.pem /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

On Debian the command reports how many certificates it added; a 0 added usually means the file did not end in .crt. For a single command, --cacert corp-root-ca.pem works without touching the system. The --ca-native flag (curl 8.2.0 and later) adds the operating system's store to the search, but what it can read depends on the TLS backend: with OpenSSL it works on Windows, and on Apple systems only when libcurl is built with Apple SecTrust (curl 8.17.0). curl --version names your backend.

Fix 3 and 4: point curl at a store that has the root

env | grep -E 'CURL_CA_BUNDLE|SSL_CERT_FILE|SSL_CERT_DIR'

Unset a stale variable or point it at the distribution bundle — /etc/ssl/certs/ca-certificates.crt on Debian and Ubuntu, /etc/pki/tls/certs/ca-bundle.crt on RHEL. A missing or empty path gives a different error, curl: (77) error setting certificate file: a bad path, not a bad chain. For an old store, upgrade the package:

sudo apt-get update && sudo apt-get install --only-upgrade ca-certificates

On Fedora and RHEL it is sudo dnf upgrade ca-certificates. And yes, -k/--insecure makes the message go away by skipping the check; the manual's own line is "WARNING: using this option makes the transfer insecure." Fine for one look at a dev box, wrong in a pipeline that downloads artifacts.

A real case: green in the browser, red on the runner

A CI runner started failing curl https://packages.example.internal/… with error 60 the morning after that server's certificate was renewed. Chrome showed a valid padlock, so the team suspected the runner's bundle. curl -v showed the normal CAfile, and openssl s_client showed a single certificate at depth 0 with Verify return code: 21. The renewal had installed cert.pem instead of fullchain.pem; Chrome had been fetching the intermediate by itself. They pointed nginx at fullchain.pem, reloaded, and the runner went green with no client change.

Verify the fix and keep it fixed

curl -sS -o /dev/null -w '%{http_code} %{ssl_verify_result}\n' https://packages.example.internal/

200 0 is what you want: ssl_verify_result is 0 only when verification succeeded, and openssl s_client should now list depth 0, 1 and Verify return code: 0 (ok). To keep it from coming back: test with curl, not a browser, after every renewal; bake the corporate CA into base images and runner templates with update-ca-certificates; keep ca-certificates in the image's regular upgrade set; and never commit -k — --cacert with a pinned bundle is the same amount of typing.

How this differs from the other 60s, and from tools with their own store

self-signed certificate without "in chain" means the server's own certificate is its issuer — an internal service whose CA you add as in Fix 2. self-signed certificate in certificate chain is the proxy case with the interception CA visible in the chain. certificate has expired is a date problem on the server, or a wrong clock on the client — check date first. SSL: no alternative certificate subject name matches target host name means the chain is fine and the URL's name is not in the certificate. Tools with their own trust store fail the same way and have their own switch: git (http.sslCAInfo), pip (--cert), Node (NODE_EXTRA_CA_CERTS).

Next time you hit this, walk these checks back in order: curl -v for the store, openssl s_client for the chain, then fix whichever side is missing the link.