Fix “unable to get local issuer certificate”

Check the server chain and the failing client’s CA store before changing certificate trust settings.

Guance Editorial Team 2026-10-27 3 min read Updated 2026-10-27

Illustration of encrypted network connections

This error means the client could not build an acceptable certificate chain to a trusted issuer. The missing piece may be in the server's intermediate chain or in the client's trust store. Updating a local CA bundle is useful only when that bundle is the problem.

Inspect both ends of the connection

Start with the original failing client. curl -v https://example.com can show its TLS backend, certificate error, and, for file-based backends, CA paths. Do not share verbose output containing credentials or sensitive headers.

Inspect what the server sends:

openssl s_client -connect example.com:443 -servername example.com \
  -showcerts -verify_hostname example.com -verify_return_error

The displayed chain is the server-supplied chain, not proof that every certificate belongs in your trust store. This command uses OpenSSL's configured trust roots, which may differ from the application's. A missing intermediate should normally be fixed on the server by deploying the correct leaf-plus-intermediate chain.

A browser can succeed because it has different trust roots or can obtain a missing intermediate. That does not mean it skipped certificate validation.

Repair an outdated system CA store

Examples for distribution-managed clients:

# Debian or Ubuntu.
sudo apt install --reinstall ca-certificates
sudo update-ca-certificates

# RHEL-family systems with the appropriate package manager.
sudo dnf reinstall ca-certificates
sudo update-ca-trust

On older supported environments, the package manager may be yum. On macOS, system clients and Homebrew-installed tools may use different trust mechanisms. Install or update the CA package used by the actual tool instead of assuming every program reads Keychain Access.

Supply a verified CA bundle explicitly

Obtain the CA material through a trusted distribution channel. The curl CA Extract page provides a Mozilla-derived public bundle; private company CAs need your organization's authenticated PKI distribution process.

curl --cacert /path/to/cacert.pem https://example.com
# For curl builds using a compatible file-based trust mechanism:
export CURL_CA_BUNDLE=/path/to/cacert.pem

For PHP, inspect the configuration loaded by the failing SAPI before setting paths:

curl.cainfo = "C:/path/to/cacert.pem"
openssl.cafile = "C:/path/to/cacert.pem"

PHP cURL and PHP streams are distinct transports. Applications can override these defaults. Reload the relevant web or PHP-FPM service after changing its effective configuration.

Git can set a repository-local CA file when its TLS backend supports that setting:

git config --local http.sslCAInfo /path/to/cacert.pem

Windows Schannel handling differs from OpenSSL-backed Git; inspect the effective backend before replacing its native trust behavior.

Check application-specific trust

For an internal CA, distribute the verified CA certificate rather than blindly trusting a leaf certificate captured from a failing connection. Debian-style local CA installation uses /usr/local/share/ca-certificates/ and update-ca-certificates; other platforms differ.

Java uses its configured trust manager and trust store. Python tooling may use system trust, certifi, or an explicit CA file depending on versions; pip supports PIP_CERT. Node.js supports NODE_EXTRA_CA_CERTS at process startup. Check the failing application rather than assuming one system update fixes all of them.

Do not use -k, http.sslVerify=false, or an accept-all trust manager as a lasting fix. They remove identity verification and do not repair the chain.

References: curl certificate verification and Git HTTP configuration.