Turning off TLS verification in code: why it ships and what to do

Turning off certificate verification, with flags like verify=False or an accept-all trust manager, makes TLS encrypt traffic to whoever answers, including an attacker in the middle. The fix is almost never to disable checks. Trust the right certificate authority, fix the hostname, or use a proper test certificate.

What the flag actually removes

Python's ssl documentation spells out the effect. With CERT_NONE on the client side, just about any certificate is accepted, and validation errors such as untrusted or expired certificates are ignored and do not stop the handshake. It also says that CERT_REQUIRED alone is not sufficient in client mode because it does not match hostnames; check_hostname must be enabled as well.

A default context created with ssl.create_default_context() turns on certificate verification and hostname checking. Weakening it is a deliberate act.

Disabling verification leaves encryption in place but removes authentication of the server. An attacker who can sit on the network path presents any certificate and the client accepts it.

Why it ends up in production

• A self-signed certificate on a dev server caused an error, and the quick fix was a flag.
• An internal CA was not in the trust store.
• A hostname did not match the certificate name.
• A certificate expired and someone needed the pipeline green.
• The flag moved from a test file into shared client code.

Better fixes for each cause

1. Internal CA: add its root certificate to the trust store used by that client, scoped to the process if possible.
2. Hostname mismatch: fix the certificate's subject alternative names, or connect with the correct name. See why SAN matters, not common name.
3. Dev servers: use a locally trusted development certificate, or a short-lived certificate from your internal CA.
4. Expired certificates: fix renewal. Our renewal automation checklist helps.
5. Pinning needs: pin deliberately with backup pins, rather than disabling checks.

Find existing instances

Search for verify=False, InsecureSkipVerify, CERT_NONE, check_hostname = False, rejectUnauthorized: false, TrustAll and empty hostname verifiers. Look in test helpers, scripts, SDK wrappers and old microservices. Add a lint rule or scan step so new instances fail review.

Try it yourself

Click through it at your own pace, or open it full screen. Look at how each result names the exact place to fix.

Quick check

Sources

• Python documentation: ssl

Last reviewed: 19 October 2026.