Python raises ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] when it cannot build a trusted chain from the server's certificate to a root CA it recognizes. Nine times out of ten the fix is a CA-bundle problem on your machine, not the target site. Here is how to diagnose it precisely — and how proxy configuration changes the picture.
The error comes from Python's ssl module during the TLS handshake: the server presented a certificate chain, and Python could not verify it against the trust store it is using. The suffix names the specific failure — "unable to get local issuer certificate" means a CA (usually an intermediate) is missing from your bundle; "certificate has expired" and "self-signed certificate" mean exactly what they say.
Crucially, Python does not automatically use your operating system's trust store in every install. requests ships with certifi, urllib relies on OpenSSL's default paths, and the python.org macOS installer uses neither until you run its certificate install step. Two programs on the same machine can disagree about the same site — which is why the URL works in your browser but fails in your script.
The other big cause class is interception: a corporate firewall, antivirus product, or TLS-inspecting middlebox that terminates your TLS session and re-signs it with its own private CA. Your browser trusts that CA because IT installed it system-wide; the CA bundle Python is using has never heard of it.
Work down this list in order — the first three items resolve most cases. Retest after each step with a simple requests.get() against the failing URL.
pip install --upgrade certifi — an outdated bundle misses newer roots and cross-signed chains./Applications/Python 3.x/Install Certificates.command — without it, that Python has no usable root store at all.openssl s_client -connect host:443 -servername host — if the server omits an intermediate certificate, the site is misconfigured and strict clients fail even when browsers cope.REQUESTS_CA_BUNDLE (or SSL_CERT_FILE) at a bundle that includes it.requests.get(url, verify=certifi.where()) removes all ambiguity about which trust store is in use.verify=False only as a short-lived diagnostic — it confirms the cause is verification, but it disables the protection entirely and does not belong in production code.A correctly configured HTTP proxy cannot cause CERTIFICATE_VERIFY_FAILED, because it does not participate in TLS. For an https:// URL, your client sends a CONNECT request, the proxy opens a raw tunnel, and the handshake runs end-to-end between you and the target. The certificate you verify is the target's own. If verification suddenly fails only when a proxy is in the loop, either the proxy is intercepting TLS or your client is speaking the wrong protocol to it.
The most common self-inflicted version is a scheme mistake: declaring the proxy itself as https:// when it accepts plain-HTTP CONNECT, which makes your client attempt a TLS handshake with the proxy port and fail in confusing ways. ProxyOmega ports are transparent tunnels — every port on residential.proxyomega.com speaks HTTP, HTTPS, and SOCKS5, and HTTPS is passed through untouched — so a certificate error through one points back at your machine's trust store or the target itself.
When you route requests through residential.proxyomega.com:10000, HTTPS traffic is tunneled via CONNECT. The proxy does not terminate or re-sign your TLS session, so the chain you verify is exactly what the target served — and verification failures are diagnosable the same way as on a direct connection.
In requests, the proxy URL for HTTPS traffic should normally be http://user:pass@host:port — the scheme describes how you talk to the proxy, not to the target. Setting it to https:// makes the client attempt TLS against the proxy port itself, producing handshake errors that look like certificate problems. SOCKS users should prefer socks5h:// so DNS resolves at the exit.
Large sites terminate TLS on regional CDN edges, and an edge in one country can serve an expired or incomplete chain while others are fine. On rotating residential proxies that shows up as an intermittent cert error. Pin the geography with -country-us on your username, or hold one exit with -session-<id>, to reproduce it deterministically. Platinum plans add state and city targeting when you need finer control.
This snippet pins an up-to-date certifi bundle and routes through a ProxyOmega residential port. HTTPS is tunneled end-to-end, so verification behaves exactly as it would on a direct connection — if this fails, the same URL will fail without the proxy too.
import requests
import certifi
proxy = "http://USERNAME:[email protected]:10000"
proxies = {"http": proxy, "https": proxy}
resp = requests.get(
"https://example.com/",
proxies=proxies,
verify=certifi.where(), # explicit, current CA bundle
timeout=30,
)
print(resp.status_code, resp.url)REQUESTS_CA_BUNDLE at a bundle containing the missing CA, or upgrade certifi if the root is public.-session-<id> on your ProxyOmega username to make the failure reproducible, then route around the broken region with country targeting.Route Python traffic through a 90M+ IP network with end-to-end TLS and a 99.7% success rate.
ProxyOmega 90M+ ethically-sourced IPs across 200+ countries and 30,000+ cities. Residential, mobile, ISP and IPv6 proxies for scraping and AI agents.