Python CERTIFICATE_VERIFY_FAILED, tested on 3.12 to 3.15

CERTIFICATE_VERIFY_FAILED means Python couldn’t trace the server’s certificate back to a root it trusts. The tail of the message tells you why, and the two I reproduced need different fixes:

1. “unable to get local issuer certificate”: antivirus or a proxy

My Windows laptop runs Avast, which scans HTTPS by re-signing every site’s certificate with its own root, “Avast Web/Mail Shield Root”. Python saw that as pypi.org’s issuer:

{'organizationalUnitName': 'generated by Avast Antivirus for SSL/TLS scanning', 'organizationName': 'Avast Web/Mail Shield', 'commonName': 'Avast Web/Mail Shield Root'}

Avast adds its root to the Windows certificate store, so browsers are fine. What Python does depends on the library. On Python 3.14.5 and 3.15.2, in fresh virtual environments:

The built-in ssl module on Windows also loads the Windows certificate store, and pip uses that store through truststore. requests trusts only the list in the certifi package, which has never heard of Avast. That’s why pip can install requests, and requests then fails on the same site.

pip install truststore

import truststore
truststore.inject_into_ssl()

import requests
requests.get("https://pypi.org/simple/")

set REQUESTS_CA_BUNDLE=C:\path\to\bundle.pem

Don’t turn verification off (verify=False) to get past this. It hides the error and also hides a real interception, which is exactly what this check exists to catch.

2. “Basic Constraints of CA cert not marked critical”: Python 3.13 and newer

This one arrives with an upgrade. Your code trusts a company or proxy root, it worked on Python 3.12, and on 3.13 it fails:

urllib.error.URLError: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: Basic Constraints of CA cert not marked critical (_ssl.c:1032)>

Python 3.13 turned on a stricter certificate check by default, the VERIFY_X509_STRICT flag. A CA certificate is supposed to mark its “Basic Constraints” field as critical, and a lot of in-house roots don’t. To test it, I made a root without that marking, signed a local HTTPS server with it, and told Python to trust the root:

The root itself is fine for 3.12; only the stricter check rejects it. truststore didn’t help here on Linux: with the root in the system store, it failed on 3.13 and newer with the same message.

import ssl
ctx = ssl.create_default_context(cafile="company-root.pem")
ctx.verify_flags &= ~ssl.VERIFY_X509_STRICT

import ssl, requests
from requests.adapters import HTTPAdapter

class CompanyRoot(HTTPAdapter):
    def init_poolmanager(self, *args, **kwargs):
        ctx = ssl.create_default_context(cafile="company-root.pem")
        ctx.verify_flags &= ~ssl.VERIFY_X509_STRICT
        kwargs["ssl_context"] = ctx
        return super().init_poolmanager(*args, **kwargs)

session = requests.Session()
session.mount("https://", CompanyRoot())

The behind-Avast case in section 1 is not this one. Avast’s root passed the strict check: with the bundle, urllib worked on 3.14 and 3.15 with the flag still on.

How this was tested

October 31, 2026. Section 1: Windows 11 Pro with Avast’s Web Shield scanning HTTPS, Python 3.14.5 (OpenSSL 3.0.20) and 3.15.2 (OpenSSL 3.5.9), each in a new virtual environment with no certificate environment variables set, requesting https://pypi.org/simple/. Section 2: GitHub Actions ubuntu-latest with Python 3.12.15, 3.13.17, 3.14.9 and 3.15.1: an OpenSSL-generated root with basicConstraints=CA:TRUE not marked critical, a server certificate signed by it for localhost, and Python’s own HTTPS server, then the same checks, and again after adding the root with update-ca-certificates. The scripts and the output are public.