Requests verifies HTTPS certificates by default. The error SSL: CERTIFICATE_VERIFY_FAILED means Python could not establish that the server’s certificate is trusted for the hostname you contacted. The right fix depends on the cause: update the active environment’s public CA data, trust an approved private or proxy CA, or correct a hostname/server mismatch. Keep verification enabled; disabling it removes important protection.
Start by identifying what failed
Capture the complete exception and the exact HTTPS hostname. Certificate errors can indicate different problems, and the remedy for a missing issuer is not the remedy for a hostname mismatch.
- Issuer or certificate chain cannot be verified: Python may lack a current public CA certificate, or the server may use a private CA that is not trusted in this environment.
- Certificate is expired: The certificate presented by the server may be out of date. The server owner needs to renew or replace it; adding a CA bundle does not make an expired certificate valid.
- Hostname does not match: The certificate may not cover the hostname in the URL, or the URL may be using the wrong hostname. Check the requested name and server configuration.
Reproduce the request with the same Python executable, virtual environment or container, and network route as the failing program. A browser can succeed while Python fails because they may use different trust stores or network configurations.
Choose the fix that matches the cause
| What is happening | What to do | Does verification stay enabled? |
|---|---|---|
| Public site; the active environment’s CA data may be missing or outdated | Check and update Requests and Certifi in that environment through your normal dependency-management workflow. | Yes |
| Private service or organization-issued certificate | Get the approved CA bundle from your administrator and configure Requests to use it. | Yes |
| HTTPS-inspecting proxy | Follow your organization’s proxy configuration and trust its approved root certificate. | Yes |
| Hostname mismatch | Verify the URL hostname and have the server present a certificate valid for that hostname. | Yes |
| A prepared request does not use environment-provided settings | Merge the session’s environment settings before sending the request. | Yes |
For a public website, update the active environment’s CA data
Requests uses Certifi as its collection of root certificates for validating TLS hosts and recommends keeping trusted certificates updated. Check the packages in the same Python environment that runs the failing code—not just a system Python or a different virtual environment. The official Requests advanced usage documentation covers SSL verification, and its recommended packages documentation identifies Certifi as the root certificate package.
#1 Best Overall
Use the package manager and dependency workflow your project normally uses to inspect or update Requests and Certifi. If the application runs in a container or deployed environment, make the change there and rebuild or redeploy as appropriate; updating packages on your workstation will not update a separate runtime.
For a private CA or HTTPS-inspecting proxy, configure the approved CA bundle
If a service uses an internal certificate authority, or a network proxy inspects HTTPS connections, ask the service or network administrator for the approved CA bundle. Use the CA certificate, not a server private key. HTTPS proxies commonly require the client to trust the proxy’s root certificate. Do not download or trust an arbitrary certificate to make the error disappear.
Set the CA bundle for one request
import requests
response = requests.get(
"https://example.com",
verify="/path/to/approved-ca-bundle.pem",
timeout=20,
)Replace the example URL and path with the service hostname and the location of the approved PEM bundle. The file must exist in the environment where the code runs and contain the appropriate CA certificate or certificates.
Set it on a session
import requests
session = requests.Session()
session.verify = "/path/to/approved-ca-bundle.pem"
response = session.get("https://example.com", timeout=20)A session setting applies to requests made through that session. Keep it scoped to the application or environment that needs the private trust anchor.
Set it for the process with an environment variable
Requests supports REQUESTS_CA_BUNDLE; CURL_CA_BUNDLE is a fallback when REQUESTS_CA_BUNDLE is not set.
export REQUESTS_CA_BUNDLE="/path/to/approved-ca-bundle.pem"Set the variable in the process environment that launches the application. If you provide a CA directory instead of a bundle file, Requests requires that directory to be processed with OpenSSL’s c_rehash.
If using PreparedRequest, merge environment settings
Requests’ prepared-request flow does not automatically apply environment settings in every case. If you use Session.prepare_request and then Session.send, merge the environment settings before sending so settings such as REQUESTS_CA_BUNDLE can be applied:
import requests
session = requests.Session()
request = requests.Request("GET", "https://example.com")
prepared = session.prepare_request(request)
settings = session.merge_environment_settings(
prepared.url,
proxies={},
stream=None,
verify=None,
cert=None,
)
response = session.send(prepared, timeout=20, **settings)For a hostname mismatch, check the URL and server certificate
Confirm that the URL uses the intended hostname and that the server presents a certificate valid for that name. Adding an unrelated CA certificate will not repair a mismatch. Requests’ FAQ notes that Python 3 includes native SNI support. If this occurs on a legacy Python 2.7 system, SNI may be relevant; Requests recommends moving to supported Python 3 rather than treating legacy behavior as a general fix.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Do not use verify=False as a permanent fix
Setting verify=False tells Requests to accept any certificate presented by the server, including one with a hostname mismatch or an expired certificate. Requests warns that this makes an application vulnerable to man-in-the-middle attacks. It is not a safe production workaround; use the correct public trust data or an administrator-approved CA bundle instead. If used for a tightly controlled local test, restore verification immediately and do not ship that setting.
Keep proxy credentials separate from certificate configuration
Proxy authentication is separate from certificate trust. Requests warns against storing proxy usernames or passwords in environment variables or version-controlled files. Follow your organization’s secret-management policy and do not commit proxy credentials or private key material to source control.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
