Ignoring SSL Verification (curl, Python, Java): Risks and Safe Fixes

“SSL accept all certificates” means your client stops checking who it is talking to. Flags such as curl -k, wget --no-check-certificate or Python’s verify=False keep encryption on but skip the certificate check, so any server – including a man-in-the-middle (an attacker who intercepts the connection) – is accepted. Use them only for a one-off local test, never in shipped code.

The better fix takes a minute: give your tool the CA certificate it is missing. Below you find the risky flag for each tool, then the safe replacement.

Is it safe to disable SSL verification in curl or Python for testing?

Only for a quick test against a machine you control, on a network you trust. Once a skip-verification flag lands in a script, a container image or production code, every connection it makes can be silently intercepted.

The danger is that nothing visibly breaks. Data still flows encrypted – just to whoever answered. Safe alternatives exist for every case:

• Proper CA bundle: update the system or language CA store when public certificates fail.
• Private CA: trust your internal root once instead of ignoring every certificate.
• Pinned test certificate: trust exactly one self-signed test certificate with --cacert or verify=.

How to disable SSL certificate checks – and what to use instead

Each block below shows the “ignore SSL certificate” option first (what NOT to ship) and then the safe fix. Replace internal-ca.pem with the PEM file of the CA that signed your server’s certificate.

curl

# Do NOT ship: accepts any certificate
curl -k https://api.internal.example.com/

# Safe: trust a specific CA file
curl --cacert internal-ca.pem https://api.internal.example.com/

# Safe: set a CA bundle for all curl calls in this shell
export CURL_CA_BUNDLE=/etc/ssl/certs/ca-bundle-with-internal.pem

wget (ignore SSL certificate)

# Do NOT ship
wget --no-check-certificate https://files.internal.example.com/app.tar.gz

# Safe
wget --ca-certificate=internal-ca.pem https://files.internal.example.com/app.tar.gz

Python requests

import requests

# Do NOT ship: also triggers InsecureRequestWarning
requests.get("https://api.internal.example.com/", verify=False)

# Safe: trust your CA bundle
requests.get("https://api.internal.example.com/", verify="/etc/ssl/certs/internal-ca.pem")

Or set REQUESTS_CA_BUNDLE=/path/to/bundle.pem in the environment. A custom bundle replaces the default one, so if you also call public sites, append your CA to a copy of the default bundle (from the certifi package) instead of using it alone.

Java: the “trust all” TrustManager

The classic Java SSL accept-all-certificates pattern is a TrustManager with empty check methods. It disables every certificate check for the whole SSLContext:

// Do NOT ship: trusts every certificate
TrustManager[] trustAll = { new X509TrustManager() {
    public void checkClientTrusted(X509Certificate[] chain, String authType) {}
    public void checkServerTrusted(X509Certificate[] chain, String authType) {}
    public X509Certificate[] getAcceptedIssuers() { return new X509Certificate[0]; }
}};
SSLContext ctx = SSLContext.getInstance("TLS");
ctx.init(null, trustAll, new SecureRandom());

The safe fix is to import your CA into a trust store. On Java 9 and later, -cacerts targets the JDK’s default store (you are prompted for its password):

keytool -importcert -cacerts -alias internal-ca -file internal-ca.pem

For one application only, create a separate store and start the JVM with -Djavax.net.ssl.trustStore=truststore.p12. That store replaces the default, so include public roots if the app needs them.

Node.js

# Do NOT ship: disables verification for the whole process
NODE_TLS_REJECT_UNAUTHORIZED=0 node app.js

# Safe: add your CA to Node's built-in roots
NODE_EXTRA_CA_CERTS=/path/to/internal-ca.pem node app.js

What does “SSL/TLS accept all certificates” mean in tools?

It is a setting in API clients, mail clients, HTTP libraries and monitoring tools that switches off certificate validation, often labeled “SSL certificate verification” or “Trust all certificates.” Its effect is the same as curl -k: encryption without authentication.

When a tool shows “verification of SSL certificates is disabled” as a warning, treat it as a to-do item. Turn verification back on and import the missing CA certificate in the tool’s settings.

How to disable Chrome checking SSL certificates

Chrome lets you click “Advanced” and proceed past a single warning, and it accepts the --ignore-certificate-errors command-line flag. Use that flag only in a throwaway test profile, because it turns off protection for every site.

The lasting fix for an untrusted SSL certificate on your own servers is to add your private root CA to the operating system’s trust store. Chrome then trusts every certificate that CA signs, with no warnings and no flags.

Tip: On a corporate network, “self signed certificate in certificate chain” often comes from a TLS-inspecting proxy. Ask IT for the proxy’s root certificate and add it to your tool’s CA bundle instead of disabling verification.

Common verification errors: cause and fix

Error message	Likely cause	Safe fix
unable to get local issuer certificate	Server sends no intermediate, or client lacks the CA	Install the full chain on the server; update the client CA bundle
self signed certificate in certificate chain	Private CA or inspecting proxy	Add that root to the client’s trust store
certificate has expired	Server certificate or an old root expired	Renew the server certificate; update the client’s root store
hostname mismatch / no alternative certificate subject name matches	You call an IP or name not in the SAN	Use the hostname on the certificate or reissue with the right SAN

The first error is often a server problem: read how the certificate chain works and install the missing intermediate. For browser-side messages, see our guide to SSL certificate errors. You can confirm the fix with the SSL checker.

Is “SSL accept all certificates” ever safe?

Practically never outside a single local test. If your server needs a certificate your clients can trust, use a private CA or a publicly trusted certificate – compare the options in self-signed vs CA-signed certificates.