Distributed systems

Unable to get local issuer certificate — repair the chain of trust

Written and reviewed by Sahil Srivastav

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

What this error actually means

The TLS verifier cannot build an acceptable certificate chain from the server’s presented certificate to a trusted certificate in the client’s trust store. The wording refers to issuer discovery in chain validation; it does not mean that you must install the website’s leaf certificate as a new trusted root.

There are two common boundaries to inspect. The server should present its leaf certificate plus the intermediate certificates needed to connect it to a trusted root. The client must have the appropriate trust anchor. A missing intermediate is a server delivery problem; an organisation’s private root absent from a minimal container is a client trust-store problem. The same curl error can result from either.

A browser succeeding is useful but not decisive. It can use a different operating-system trust store or have an intermediate available that the command-line environment lacks. Run diagnostics from the failing container or host and inspect the curl TLS backend. Testing only your workstation often verifies a different trust environment entirely.

Causes, most common first

  1. 1The server omits an intermediate certificate. A deployment installs the leaf certificate where the TLS terminator expects a chain file. Some clients still succeed because their environments already know the missing intermediate; fresh containers expose the incomplete server chain.
  2. 2The client image has no suitable CA roots. Minimal images may omit the CA package, ship an outdated bundle, or use a runtime with its own trust store. Installing roots on the host does not automatically update a container or a bundled application runtime.
  3. 3A private CA or approved TLS inspection proxy is involved. The certificate chain terminates at an organisation-controlled authority outside public trust stores. The correct trust anchor must come through a trusted administrative channel, not from whatever certificate an unverified network connection happens to present.
  4. 4An override points curl at the wrong CA bundle. CURL_CA_BUNDLE, SSL_CERT_FILE or build-specific defaults can direct the client away from the expected store. A successful system package update will not help a process still using an obsolete private bundle.

When you see it

  • curl fails with code 60 from a container while a browser on a managed laptop connects.
  • The failure begins after certificate renewal or an ingress certificate replacement.
  • Only requests through a corporate network show an unexpected certificate issuer.
  • Passing a known organisation CA bundle succeeds while the default trust store fails.

How to diagnose it

Step 1

Identify the curl build and observed certificate failure

Run from the failing environment. curl -V names its TLS backend; verbose connection output commonly reveals relevant trust paths and handshake details. Redact credentials and cookies before sharing verbose logs.

curl -V
curl -v --max-time 15 https://api.example.com/ -o /dev/null

Step 2

Inspect the chain with the correct server name

SNI selects the intended certificate on shared TLS endpoints. Verify the hostname explicitly and stop on verification failure. This command uses OpenSSL’s trust configuration, which can differ from curl’s, so compare rather than assuming identical results.

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

Step 3

Check CA-path overrides

Inspect the relevant variables in the process environment. Do not dump the whole environment because it can contain secrets. Compare the paths with the store actually shipped in the failing image and with curl’s backend-specific behaviour.

printenv CURL_CA_BUNDLE SSL_CERT_FILE SSL_CERT_DIR

Step 4

Test a trusted, explicit CA bundle

Obtain the bundle from your CA administrator or approved image source before running this example. Success with a legitimate private root isolates the client trust gap. Failure with a correct public bundle points back towards the presented chain or another certificate validation issue.

curl --cacert /etc/company/approved-ca-bundle.pem --max-time 15 https://api.example.com/ -o /dev/null

The fix

When the server chain is incomplete, configure the TLS terminator with the leaf certificate followed by the required intermediate chain in the order expected by that server. You ordinarily do not need to serve the root. Validate the deployed endpoint from a clean client after renewal rather than validating only certificate files on disk.

When a legitimate trust root is absent, install the maintained CA bundle through the image build or the runtime’s supported trust configuration. For a private authority, distribute the approved root with an auditable source and rotation process. Keep the scope as narrow as the application requires rather than trusting arbitrary captured certificates.

Remove stale overrides or update the application-specific store that actually performs verification. A Java process, Python package, native curl build and operating-system browser can all use different stores; repair the failing runtime’s trust path and test that runtime directly.

Do not retain curl -k or disabled certificate verification as the fix. It removes the authentication guarantee needed to know which server received your credentials and data. If a diagnostic bypass confirms verification is the failing stage, restore verification immediately and repair the chain before treating the connection as trustworthy.

How to stop it coming back

  • Test certificate renewal against fresh minimal clients, including the container image used in production.
  • Version and maintain private CA distribution alongside image dependencies, with overlap during planned root rotation.
  • Monitor deployed chain completeness and expiry separately; an unexpired leaf can still have an unusable chain.

Practise production debugging in a real repository

Reading about a failure and reproducing one are different skills. Gronex ships broken backend repositories with failing test suites that encode the real invariant, so you debug from evidence instead of memorising symptoms.

FAQ

Should I download the issuer certificate and trust it?

Only obtain trust anchors through an authenticated source you already trust. The certificate presented by the failing connection is evidence to inspect, not authority to expand your trust store. A missing intermediate normally belongs in the server’s served chain.

Is this the same as a hostname mismatch?

No. Chain trust and hostname identity are separate validation requirements, although curl reports several verification failures under code 60. Read the exact message and verify both before concluding that adding a CA will solve the incident.

Why does OpenSSL pass but curl fail?

They can use different TLS backends, CA stores and environment overrides. Run curl -V, inspect its verbose trust information and compare the same server name from the same environment. One tool’s trust result does not establish another’s configuration.

Related

502 from an upstream TLS failureConnection reset on a long-poll endpoint

Other errors engineers hit next to this one

Full error and symptom index →