"SSL certificate problem: unable to get local issuer certificate": fix the chain, not the check

1. Look at the chain

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

At the top, under Certificate chain, every certificate the server sent has two lines: s: (subject — who it is) and i: (issuer — who signed it). At the bottom, the verdict:

Certificate chain
 0 s:CN = intranet.example.com
   i:C = US, O = Let's Encrypt, CN = R11
---
...
Verify return code: 21 (unable to verify the first certificate)

Verify return code: 0 (ok) means OpenSSL on this machine trusts the server, and the problem is in the specific tool (section 4). Anything else, read on.

2. The server sends an incomplete chain

Above, the server sent only its own certificate (0 s:), not the intermediate R11 that signed it. The client has no way to reach a trusted root. This is a server-side mistake, usually from configuring the certificate file instead of the full chain.

Browsers often still show the site as secure — they cache intermediates they’ve seen before, or download missing ones — which is why “it works in Chrome” proves nothing here. curl, Git, Python and Node.js don’t do that.

Fix it on the server. With Let’s Encrypt, use fullchain.pem, not cert.pem:

ssl_certificate     /etc/letsencrypt/live/intranet.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/intranet.example.com/privkey.pem;

With a certificate bought elsewhere, put your certificate first and the intermediate(s) after it in one file: cat example.com.crt intermediate.crt > fullchain.crt. Check again with openssl s_client: you should now see 1 s: too, and Verify return code: 0 (ok).

3. A company proxy or a private CA

If the issuer (i:) of the top certificate is your company, your antivirus or a security product (Zscaler, Netskope, Fortinet, Palo Alto…) instead of a public CA, then something on your network opens HTTPS traffic to inspect it and re-signs it with its own root certificate. The same happens with internal sites signed by a company CA. Your machine doesn’t know that root yet.

Get the company root certificate (from IT, or export it from the browser, which usually has it already) in PEM format, and add it to the system’s CA store:

# Debian / Ubuntu — the file must end in .crt
sudo cp company-root.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

# RHEL / Rocky / AlmaLinux
sudo cp company-root.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

curl, wget, Git and most system tools use this store and work right away.

4. Tools with their own CA store

Some runtimes don’t use the system store — they bring their own list, so step 3 isn’t enough for them:

In Docker images, the store is inside the image. Slim images often don’t even have ca-certificates. Add both in the Dockerfile:

RUN apt-get update && apt-get install -y --no-install-recommends ca-certificates && rm -rf /var/lib/apt/lists/*
COPY company-root.crt /usr/local/share/ca-certificates/
RUN update-ca-certificates

If even public sites like https://github.com fail, the store itself is missing or broken: sudo apt install --reinstall ca-certificates (or sudo dnf reinstall ca-certificates).