How to Fix curl (60): unable to get local issuer certificate

What error 60 is actually telling you

TLS trust works as a chain. A website presents a leaf certificate, which is signed by one or more intermediate certificates, which trace back to a root certificate that your machine already trusts. curl validates by walking that chain from leaf to root. Error 60 means the walk broke: curl reached a link it couldn't verify because the issuer of the current certificate wasn't provided by the server and isn't in curl's local trust store.

"Unable to get local issuer certificate" is precise wording, curl needs the issuer (the certificate that signed the one it's holding) and can't find it locally. That points to exactly two root causes, and telling them apart is the whole job.

The two real causes

Cause one: the server sends an incomplete chain. The most common culprit. A correctly configured server must send its leaf certificate plus every intermediate, the root can be omitted because clients already have it. If the admin installed only the leaf and forgot the intermediate bundle, curl gets the leaf, has no way to reach the root, and fails. Browsers often paper over this by caching intermediates from previous sites, which is why "it works in Chrome but fails in curl" is such a classic symptom.

Cause two: your local CA bundle is missing or stale. curl needs a file of trusted root certificates. On minimal Docker images, freshly installed servers, or old systems, that bundle can be absent or out of date, so even a perfectly configured server fails because curl trusts nothing. This is common in alpine containers that ship without ca-certificates installed.

Diagnose before you fix

Don't guess which cause you have, check. Run OpenSSL against the host and read the chain it returns:

openssl s_client -connect example.com:443 -showcerts. Look at the certificates listed. If you see only one certificate (the leaf) and the verify line reads "unable to get local issuer certificate," the server is sending an incomplete chain, that's cause one. If you see a full chain but curl still fails, your local trust store is the problem, that's cause two. You can also confirm from the client side that the server's chain is complete using a free SSL certificate checker, which flags missing intermediates explicitly.

• One cert returned + verify error → server is missing intermediates (fix the server).
• Full chain returned but curl still errors → client CA bundle missing or stale (fix the client).
• Works in a browser but not curl → almost always a missing intermediate the browser cached.

The correct fix for each cause

If the server is missing intermediates, fix it there, this is the real fix, because every strict client (curl, Java, Go, mobile apps) will otherwise keep failing. Reinstall the certificate with the full chain: concatenate your leaf certificate and the CA-provided intermediate bundle into the file your server points to (for nginx, that's the ssl_certificate fullchain file; certbot's fullchain.pem already does this). Reload the server and re-test with openssl, you should now see the complete chain.

If your client CA bundle is the problem, refresh it. On Debian/Ubuntu: apt-get install -y ca-certificates && update-ca-certificates. On alpine: apk add --no-cache ca-certificates. On RHEL/CentOS: update-ca-trust. This installs the current root set curl validates against, and legitimate sites start verifying immediately.

Workarounds, and the one to never use

If you need a request to succeed right now against a specific host whose chain you trust, point curl at a known-good CA bundle instead of disabling security: curl --cacert /path/to/ca-bundle.crt https://example.com, or set the CURL_CA_BUNDLE environment variable. For an internal or self-signed CA, add that CA's certificate to your trust store or pass it with --cacert, this keeps verification on, just against a bundle that includes your issuer.

What you must not do in anything that matters: curl -k (or --insecure). It doesn't fix the chain, it turns off certificate verification entirely, so curl will happily talk to an impostor. It's fine for a throwaway debug against localhost; it's a security hole in a script, a cron job, or production code. If you catch yourself reaching for -k to silence error 60, stop and fix the actual chain instead.

Stop it from coming back

Error 60 from a missing intermediate is a certificate that will keep biting you, and the same servers that ship an incomplete chain tend to be the ones whose certificate quietly expires, too. A one-time openssl check confirms today's chain is complete; it won't catch the renewal three months from now that reintroduces the problem, or the expiry that takes the site down entirely. Continuous SSL and certificate monitoring validates the full chain and expiry on a schedule and alerts you before a client's browser, or your curl script, ever sees the error. If you're currently staring at a related failure, our guide on an expired SSL certificate covers the neighboring case.