Introduction

certificate verify failed: unable to get local issuer certificate means the client could not build a trusted certificate chain from the server certificate up to a CA in the local trust store. In plain terms, the TLS connection reached a certificate, but the client could not verify who signed it with a chain it trusts.

What the Error Usually Means

During a TLS handshake, the server sends its certificate and usually one or more intermediate certificates. The client then tries to connect that chain to a trusted root CA installed locally.

If any part of that chain is missing or untrusted, verification fails.

Typical causes include:

• The server is not sending required intermediate certificates
• The client trust store is outdated
• A corporate proxy is replacing certificates
• The server uses a self-signed certificate
• The application points at the wrong CA bundle

This Python example shows the kind of request that often triggers the error:

1import requests
2
3response = requests.get("https://example.com")
4print(response.status_code)

If certificate verification fails, the exception is telling you the trust chain could not be completed correctly.

Fix the Trust Store Before Disabling Verification

The safest fix is almost always to correct the CA chain rather than turning verification off.

If you are using Python, certifi is a common CA bundle source:

1import certifi
2import requests
3
4response = requests.get(
5    "https://example.com",
6    verify=certifi.where(),
7)
8print(response.status_code)

That can help when the runtime's certificate bundle is stale or misconfigured.

On Linux systems, updating the OS CA store is also common. The exact command depends on the distribution, but the principle is the same: refresh the trusted certificate bundle so the client recognizes modern issuers.

Check the Server Certificate Chain

Sometimes the client is fine and the server is the real problem. A misconfigured web server may present only the leaf certificate without the required intermediates.

You can inspect the chain with OpenSSL:

openssl s_client -connect example.com:443 -showcerts

If the intermediate certificates are missing, many clients will report the local issuer error even though the root CA is widely trusted. The fix then belongs on the server: install the full certificate chain properly.

Self-Signed and Internal Certificates

In development or internal environments, the server may use a self-signed certificate or a private CA. In that case, the client must explicitly trust that CA.

For example, if you have an internal CA certificate file:

1import requests
2
3response = requests.get(
4    "https://internal.example.local",
5    verify="/path/to/internal-ca.pem",
6)
7print(response.status_code)

This is very different from verify=False. You are still verifying the certificate, just against your internal CA rather than the public internet CA bundle.

What Not to Do

This is tempting:

requests.get("https://example.com", verify=False)

It may make the error disappear, but it also disables certificate verification and opens the door to man-in-the-middle attacks. That is acceptable only for narrow debugging scenarios, not as a real fix.

Common Pitfalls

The biggest mistake is treating the error as a purely client-side bug. Many times the real issue is a server that is not presenting the full chain.

Another problem is copying verify=False from a forum answer and leaving it in production code. That solves the symptom while removing one of the core protections TLS is supposed to provide.

Developers also sometimes update one CA store and forget that the actual runtime uses a different one. A system Python, virtual environment, container image, Java runtime, and operating system can all rely on different certificate stores.

Finally, remember that internal proxies and SSL inspection tools can replace certificates on the fly. If the network path inserts its own CA, the client must trust that CA explicitly or the handshake will fail.

Summary

• The error means the client could not build a trusted certificate chain to a local root CA.
• Common causes are missing intermediates, stale trust stores, self-signed certificates, or network interception.
• Fix the CA bundle or the server chain instead of disabling verification.
• Use tools such as openssl s_client to inspect what the server actually sends.
• 'verify=False is a debugging shortcut, not a secure production solution.'