[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate

Python · updated 2026-11-03

Raised by ssl, urllib, requests, httpx and aiohttp when opening an HTTPS connection whose certificate chain cannot be traced to a trusted root. The part after the colon says why: an unknown issuer, an expired certificate or a hostname mismatch.

Traceback (most recent call last):
  ...
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1006)

During handling of the above exception, another exception occurred:
...
requests.exceptions.SSLError: HTTPSConnectionPool(host='api.example.com', port=443): Max retries exceeded with url: /v1/orders (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1006)')))

Quick fix

Make sure Python has a current CA bundle: update certifi (pip install -U certifi), install ca-certificates in slim Docker images, and on macOS python.org builds run "Install Certificates.command". If a corporate proxy re-signs traffic, point REQUESTS_CA_BUNDLE or SSL_CERT_FILE at its CA. Turning verification off hides the problem and exposes the traffic.

Read the reason after "certificate verify failed": unknown issuer, expired, or hostname mismatch.
Upgrade certifi and, in containers, install the OS ca-certificates package.
On macOS with a python.org installer, run /Applications/Python 3.x/Install Certificates.command.
Behind a TLS-inspecting proxy, set REQUESTS_CA_BUNDLE (requests) or SSL_CERT_FILE to the proxy CA file.
If the server itself sends an incomplete chain or an expired certificate, the fix belongs on that server.

bash

# Update the CA bundle Python uses
pip install -U certifi
python -c "import certifi; print(certifi.where())"

# Slim Debian/Ubuntu images often lack system CAs
apt-get update && apt-get install -y ca-certificates

# Behind a corporate proxy that re-signs TLS
export REQUESTS_CA_BUNDLE=/etc/ssl/certs/corp-proxy-ca.pem
export SSL_CERT_FILE=/etc/ssl/certs/corp-proxy-ca.pem

Why it happens

Missing or outdated CA certificates

Minimal Docker images, old certifi versions and python.org builds on macOS can lack the root certificates needed to verify common sites.

A proxy that inspects TLS

Corporate networks and some antivirus tools replace site certificates with their own. Browsers trust the company CA through the OS, but Python's certifi bundle doesn't.

The server sends an incomplete chain

A server that omits the intermediate certificate works in browsers (which fetch missing intermediates) but fails in Python, which does not.

An expired or mismatched certificate

"certificate has expired" or "hostname mismatch" in the message means the problem is the server certificate or the URL you used, not your machine.

Other fixes

Never ship verify=False or an unverified SSL context to production: it removes protection against interception.
Pin a CA bundle path in config for internal services signed by a private CA.

Same error, other wording

[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate in certificate chain
[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: certificate has expired
urllib.error.URLError: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1006)>

Let your coding agent catch the next one

Runheed records this error in production with the stack trace, the breadcrumbs before it and the agent session that shipped the code, and serves it to Claude Code, Cursor or any MCP client. With it connected, you can ask:

> Find the CERTIFICATE_VERIFY_FAILED errors in production, show me which hosts they hit and the exact reason in each message, and fix the CA setup (certifi, ca-certificates, or a configured bundle) without disabling verification.

Plans from $29/mo See what your agent reads See the setupCancel any time from the billing portal