unable to get local issuer certificate

What the error actually means #

Verification walks a chain. Your server certificate says “I was signed by Example Intermediate CA”, so the verifier looks for a certificate belonging to Example Intermediate CA, then asks who signed that, and continues until it reaches a certificate in the local trust store.

This error is emitted at the moment that walk fails: the verifier holds a certificate, knows the name of its issuer, and cannot find a certificate for that issuer anywhere. It is a missing link, not an invalid signature and not an expired certificate.

There are exactly two places the link can be missing from, and the fix is completely different for each.

Step 1 — find out which cause you have #

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

Count the -----BEGIN CERTIFICATE----- blocks in the output:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null \
| grep -c "BEGIN CERTIFICATE"

Cause A — the server is not sending its intermediates #

A TLS server is required to send its own certificate and every intermediate needed to reach a trusted root. Serving only the end-entity certificate is the single most common cause of this error.

The fix is to concatenate the certificates into one file, leaf first, then each intermediate in order, walking up toward the root:

cat certificate.crt intermediate.crt > fullchain.crt

Then point the server at the combined file:

ssl_certificate     /etc/ssl/certs/fullchain.crt;
ssl_certificate_key /etc/ssl/private/private.key;

SSLCertificateFile    /etc/ssl/certs/fullchain.crt
SSLCertificateKeyFile /etc/ssl/private/private.key

cat certificate.crt intermediate.crt private.key > /etc/haproxy/certs/site.pem

Reload the service, then confirm the chain is complete:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
| grep "Verify return code"

Verify return code: 0 (ok)

Where do I get the intermediate? #

Your CA publishes it, and the certificate itself tells you where. Read the CA Issuers URL out of the Authority Information Access extension:

openssl x509 -in certificate.crt -noout -text \
| grep -A1 "Authority Information Access"

Authority Information Access:
  OCSP - URI:http://ocsp.example-ca.com
  CA Issuers - URI:http://crt.example-ca.com/intermediate.der

That file is usually DER-encoded, so convert it to PEM before concatenating it.

Cause B — the root is not in your trust store #

If the server returns a complete chain and verification still fails, the root CA at the top of that chain is not trusted by whatever is doing the verifying. This is normal for a private or corporate CA, and for containers built FROM scratch that ship no CA bundle at all.

You can confirm it by verifying against the root explicitly. If this succeeds, the certificate is fine and only trust is missing:

openssl verify -CAfile root-ca.crt -untrusted intermediate.crt certificate.crt

certificate.crt: OK

Then install the root:

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

sudo cp root-ca.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust extract

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

sudo security add-trusted-cert -d -r trustRoot \
-k /Library/Keychains/System.keychain root-ca.crt

Runtimes that ignore the system trust store #

Several runtimes ship their own CA bundle and will keep failing after you have fixed the system store. Point each at the right bundle:

What not to do #