Introduction

In requests, disabling certificate verification is done with verify=False, but that should be treated as a narrow debugging or local-development tool, not a normal production configuration. The better long-term fix is usually to trust the correct certificate authority bundle or the server's internal CA instead of turning TLS verification off entirely.

The Direct Mechanism

The basic syntax is simple:

1import requests
2
3response = requests.get("https://example.internal", verify=False, timeout=10)
4print(response.status_code)

That tells requests not to verify the server certificate chain or hostname in the normal way.

You can do the same on a session:

1import requests
2
3session = requests.Session()
4session.verify = False
5response = session.get("https://example.internal/api", timeout=10)
6print(response.text)

Both forms work. The danger is what they permit.

Why This Is Dangerous

TLS verification is what helps confirm that the server you reached is the server you intended to reach. Once you disable verification, an attacker or misconfigured proxy can present any certificate and the client may still proceed.

That opens the door to:

• man-in-the-middle interception
• accidental connection to the wrong endpoint
• false confidence that the connection is secure because it still says https

So the code is easy. The consequences are the real issue.

Suppressing The Warning

When you use verify=False, urllib3 emits InsecureRequestWarning. That warning exists for a good reason.

If you are working in a short-lived local debugging scenario and need to suppress the warning noise temporarily, do it explicitly:

1import requests
2import urllib3
3
4urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)
5
6response = requests.get("https://example.internal", verify=False, timeout=10)
7print(response.status_code)

Do not treat warning suppression as a security fix. It only hides the reminder.

The Better Fix: Trust The Right CA Bundle

If the server uses an internal or self-signed certificate, the safer approach is to point requests at the CA certificate file that should be trusted.

1import requests
2
3response = requests.get(
4    "https://example.internal",
5    verify="/path/to/internal-ca.pem",
6    timeout=10,
7)
8print(response.status_code)

This preserves TLS verification while teaching the client which certificate authority to trust.

That is usually the right answer for:

• internal development environments
• staging systems with private PKI
• corporate networks using internal certificate authorities

Environment-Controlled Behavior

If you absolutely must allow insecure mode in development, gate it with configuration so the unsafe behavior cannot quietly leak into production.

1import os
2import requests
3
4verify_tls = os.getenv("APP_VERIFY_TLS", "true").lower() == "true"
5response = requests.get("https://example.internal", verify=verify_tls, timeout=10)
6print(response.status_code)

This is still risky if someone flips the environment variable in production, but it is better than hardcoding verify=False in application logic.

An even better variant is to choose between a CA bundle path and the normal default verification path rather than a binary secure-versus-insecure switch.

Common Causes Of Certificate Failures

Before disabling verification, identify why the handshake failed.

Typical causes are:

• self-signed or private CA certificates
• hostname mismatch between the URL and certificate subject
• expired certificate
• intercepted HTTPS traffic through a corporate proxy
• missing local CA trust store

Each of those has a different proper fix. Disabling verification bypasses all of them indiscriminately, which is why it is a poor long-term solution.

A Safer Pattern For Internal Services

If the real issue is a private certificate chain, a safer pattern is:

1. export the internal CA certificate
2. store it in a controlled location
3. point requests to that CA bundle
4. keep verify=False out of production code entirely

That preserves TLS semantics and avoids teaching developers that certificate verification is optional by default.

Common Pitfalls

• Leaving verify=False in production code after a temporary test.
• Suppressing InsecureRequestWarning and mistaking that for a security fix.
• Disabling verification when the real problem is just a missing internal CA certificate.
• Ignoring hostname mismatch errors that indicate the certificate was issued for a different name.
• Applying an unsafe session-wide configuration when only one temporary request needed investigation.

Summary

• In requests, certificate verification can be disabled with verify=False.
• That should be limited to narrow debugging scenarios, not normal production use.
• The safer fix is usually to pass a trusted CA bundle path to verify.
• Warning suppression only hides the message; it does not reduce the risk.
• Treat TLS verification failures as configuration problems to fix, not as obstacles to bypass casually.