What does curl -k do?

Skips SSL certificate verification — cURL doesn't check if the cert is valid, signed by a trusted CA, expired, or matches the hostname. The TLS connection still encrypts, but you lose the guarantee that you're talking to the legitimate server. A man-in-the-middle attack would succeed silently.

Is curl -k safe to use?

In local dev with self-signed certs: yes, with care. In production: no, never. The flag disables the entire trust model that makes HTTPS secure. Production scripts using -k can't tell a real server from an attacker's proxy.

How do I trust a self-signed cert without -k?

Use --cacert /path/to/cert.crt — cURL trusts that specific cert for this request without disabling system-wide verification. For corporate CAs that you need everywhere, import the CA into your system trust store with update-ca-certificates (Linux) or security add-trusted-cert (macOS).

Why does curl fail with SSL errors but the browser works?

Browsers ship with their own trust store and update it via auto-update. cURL uses your system trust store, which may be outdated or missing CAs the browser trusts. Update ca-certificates, or check if you're behind a corporate proxy that intercepts HTTPS (those add their own CA to the browser but not to system store).

How do I ignore SSL in Python requests?

Same warning applies: only for dev. requests.get(url, verify=False) disables verification. To suppress the InsecureRequestWarning: import urllib3; urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning). For production, use requests.get(url, verify='/path/to/cacert.pem') with a proper CA bundle.

Does -k mean traffic is unencrypted?

No — the TLS encryption still happens. -k only disables the cert verification step. Data on the wire is still encrypted. The risk is that an attacker who can intercept your connection (e.g., compromised WiFi) could present their own cert, decrypt your traffic, and re-encrypt to the real server, without you knowing.

What's the difference between -k and --proxy-insecure?

-k disables verification of the TARGET server's cert (the upstream you're trying to reach). --proxy-insecure disables verification of the PROXY's cert (only relevant for HTTPS proxies). They're independent flags — you can use both for fully-disabled verification, or just one when only one chain is problematic.

cURL Ignore SSL: The -k Flag and When to Use It

Q: What does 'SSL certificate problem: unable to get local issuer certificate' mean?

The server's cert is signed by a CA that your system doesn't trust. Three causes: (1) your CA bundle is outdated — update ca-certificates package; (2) self-signed cert — use --cacert; (3) corporate CA not installed — import the corporate root CA into your trust store. Don't use -k as the fix.

Quick verdict: cURL's -k (or --insecure) skips SSL certificate verification entirely. Use it ONLY for local testing, self-signed certificates in dev environments, or one-off debugging. Never use it in production scripts — you lose the security guarantee that you are talking to the right server. The right fix for a "cert verification failed" error is almost always to use --cacert /path/to/ca-bundle.crt or to fix the cert chain.

The Flag

# Long form
curl --insecure https://localhost:8443

# Short form
curl -k https://localhost:8443

Both are identical. With this flag:

cURL does not check if the cert is signed by a trusted CA
cURL does not check if the cert is expired
cURL does not check if the cert hostname matches the URL
The TLS connection still encrypts, but you cannot verify the server identity

When -k Is Acceptable

Local dev with self-signed certs: running a Flask/Express app with a quick openssl req -newkey ... generated cert.
Internal testing: staging environment behind a corporate CA that is not in your system trust store.
One-off debug: proving a connection works before fixing the cert.
Health checks against IP, not hostname: the cert is for api.example.com but you are checking 192.168.1.10.

When -k Is Dangerous

Production scripts: you would not know if a man-in-the-middle intercepted your connection.
CI/CD pipelines pulling secrets: a compromised network could feed false data.
Anything touching customer data: compliance frameworks (PCI-DSS, HIPAA, SOC 2) explicitly forbid disabling cert validation.
Scripts that ship to other machines: the disable flag travels with the script forever.

If your production script needs -k "just to make it work," you have a cert problem. Fix the cert.

The Right Alternatives

1. Self-signed cert: --cacert

Trust a specific cert without disabling all verification:

curl --cacert /path/to/server.crt https://localhost:8443

cURL uses server.crt as the CA bundle for THIS request only. The rest of the system trust store is unchanged.

2. Corporate CA: --capath or system trust

Add the corporate root CA to your system trust store:

# Linux (Debian/Ubuntu)
sudo cp corp-root-ca.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

# macOS
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain corp-root-ca.crt

# Windows (cURL ships with its own bundle)
curl --cacert C:path	ocorp-ca.crt https://internal.corp.local

After this, normal curl works without flags.

3. Hostname mismatch: --resolve

If your cert is for api.example.com but you want to test against IP 10.0.0.5:

curl --resolve api.example.com:443:10.0.0.5 https://api.example.com/health

cURL sends a SNI for api.example.com, validates the cert against that hostname, but actually connects to 10.0.0.5. Keeps verification on.

Common SSL Errors That Tempt -k

SSL certificate problem: unable to get local issuer certificate

Your system trust store does not have the CA that signed the server's cert. Fixes:

Update ca-certificates package: apt update && apt install --reinstall ca-certificates
If self-signed: use --cacert as above
If corporate CA: import the CA into the system store

SSL: no alternative certificate subject name matches target host name

The cert is valid but for a different hostname. Solutions:

Hit the actual hostname the cert is for
Use --resolve hostname:port:ip as above
Regenerate the cert with SAN entries for all hostnames you use

SSL certificate has expired

Renew the cert. -k would mask this and let your script keep "working" on an expired cert — bad. Set up Let's Encrypt + certbot for auto-renewal.

SSL Verification With Proxies

When using a proxy with HTTPS, cURL needs to verify two cert chains: the proxy itself, and the target through the proxy. Separate flags:

# Skip target cert check only
curl --proxy http://gw.spyderproxy.com:8000 -k https://target.com

# Skip proxy cert check only (rare, HTTPS proxies)
curl --proxy https://proxy.example.com:8000 --proxy-insecure https://target.com

# Trust specific cert for the target
curl --proxy http://gw.spyderproxy.com:8000 --cacert target.crt https://target.com

For SpyderProxy and most commercial residential proxies, the proxy uses standard CA-signed certs — no flags needed. The flags above are only for self-signed proxy setups.

Equivalents in Other Tools

Tool	Disable SSL verification
cURL	`-k` or `--insecure`
Python requests	`verify=False`
Python urllib	`context=ssl._create_unverified_context()`
aiohttp	`connector=aiohttp.TCPConnector(ssl=False)`
httpx	`verify=False`
Node.js fetch	`NODE_TLS_REJECT_UNAUTHORIZED=0` env var
wget	`--no-check-certificate`
git	`git config --global http.sslVerify false` (bad idea)

All have the same warning: convenient for dev, dangerous for prod.

Auditing -k Usage

Find every script in a codebase that uses -k:

grep -rn "curl.*-k|curl.*--insecure" .

Each match deserves a comment explaining why, or a refactor to remove. CI security scanners (Snyk, Semgrep) flag this pattern as a code smell.