Fix: SSL certificate problem: unable to get local issuer certificate

If you are seeing SSL certificate problem: unable to get local issuer certificate, the client opened a TLS connection but could not link the server certificate back to a root it trusts, so it refused to continue. This is a trust problem, not a sign that the certificate is fake or expired. The verifier found a certificate it could not vouch for because a link in the chain is missing.

What this error means

Every TLS certificate is signed by an issuer, which is signed by another issuer, up to a root certificate authority (CA) that your system already trusts. To verify a server, the client walks that chain from the leaf certificate up to a trusted root. This error means the walk stopped early: the client could not find the issuer needed to reach a root it recognizes.

There is a tempting shortcut you should avoid. Do not fix this by disabling verification (curl -k, NODE_TLS_REJECT_UNAUTHORIZED=0, or verify=False in Python). Those flags silence the check that proves you are talking to the real server, which removes the protection TLS exists to give you. Treat them as debugging tools only, never a production fix.

Common causes

• The server is not sending its intermediate certificate(s), so the client receives an incomplete chain. This is the most common cause.
• The client CA bundle is outdated or missing, for example an old ca-certificates package or a slim container image that never installed one.
• A corporate TLS-inspecting proxy is re-signing traffic with its own root that your client does not trust.
• A self-signed or private CA certificate is in use and has not been installed on the client.
• A language runtime is pointed at the wrong bundle, so the OS trust store is fine but the app cannot see it.

How to fix it

Stabilize

If a job or deploy is blocked, keep the connection secure. Do not disable verification to get moving. Instead, point the client at a known good bundle temporarily while you diagnose, for example by installing ca-certificates in the container or exporting a correct bundle path. Verification stays on, and you buy time to find the real cause.

Diagnose

1. Inspect the chain the server actually presents:

openssl s_client -connect example.com:443 -servername example.com -showcerts

Read the certificate list and the Verify return code line at the bottom. Code 21 (unable to verify the first certificate) or a chain that stops at the leaf points to a missing intermediate.

2. Confirm with curl, which uses your client trust store:

curl -v https://example.com

3. Check where your runtime looks for its bundle so you fix the right layer:

openssl version -d
python -c "import certifi; print(certifi.where())"

Fix by cause

1. Server sending an incomplete chain. Rebuild the certificate file so it includes the leaf followed by the intermediate(s), then reload. For nginx, point ssl_certificate at the full chain:

cat leaf.crt intermediate.crt > fullchain.pem
sudo nginx -t && sudo systemctl reload nginx

2. Outdated or missing client bundle. Update the trust store on the client:

# Debian and Ubuntu
sudo apt-get update && sudo apt-get install -y ca-certificates
sudo update-ca-certificates
# RHEL, Fedora, Alma
sudo update-ca-trust

3. Runtime pointed at the wrong bundle. Direct the language to the correct file:

export REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt
export NODE_EXTRA_CA_CERTS=/etc/ssl/certs/ca-certificates.crt
git config --global http.sslCAInfo /etc/ssl/certs/ca-certificates.crt

4. Corporate proxy or private CA. Install the root into the trust store rather than disabling verification:

sudo cp corporate-root.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

How to prevent it

• Always deploy the full chain (fullchain.pem), never the leaf certificate alone.
• Keep ca-certificates installed and updated in every image, including slim and distroless base layers.
• Install corporate and private roots through the trust store, never by turning verification off.
• Pin runtime bundle paths (REQUESTS_CA_BUNDLE, NODE_EXTRA_CA_CERTS) in config, not ad hoc in a shell.
• Add an automated check that runs openssl s_client against your endpoints so a broken chain is caught before users are.

When to call a senior engineer

Call for help when the chain looks correct in openssl but requests still fail across multiple services, when a TLS-inspecting proxy makes the trust picture ambiguous, or when the temptation to disable verification is growing under deadline pressure. A senior engineer can trace exactly which layer, from server to OS to runtime, is breaking trust and fix it without weakening security. Erzon can join a live incident and resolve the chain properly while you keep shipping.