Keep TLS verification enabled

For HTTPS, curl checks two things about the server’s certificate. That it chains to a trusted authority. And that it matches the hostname you asked for.

Both checks protect the server’s identity. The chain check proves someone trusted vouched for this certificate. The hostname check proves the certificate was issued for this name, not some other site.

Skip either one and encryption still happens. You just no longer know who you’re encrypting to.

Watch a verification succeed

Inspect a normal verified connection:

curl --verbose https://example.org/ -o /dev/null

In the * lines, find the certificate subject, issuer, and result:

* Server certificate:
*  subject: CN=example.org
*  subjectAltName: host "example.org" matched cert's "example.org"
*  issuer: C=US; O=SSL Corporation; CN=Cloudflare TLS Issuing ECC CA 3
*  SSL certificate verify ok.

The subjectAltName ... matched line is the hostname check passing. verify ok is the chain check passing. Both, for this connection.

When verification fails

A failure looks like this:

curl: (60) SSL certificate problem: unable to get local issuer certificate

Exit code 60 is information, not an obstacle. Every cause has a real fix.

A hostname mismatch means you’re connecting to a name the certificate doesn’t cover. Fix the URL, or fix the certificate.

An incomplete chain means the server forgot to send an intermediate certificate. Fix the server config. You can confirm it with an online checker or with openssl s_client.

An unknown authority on a corporate network or private CA means curl needs that CA added:

curl --cacert internal-ca.pem https://intranet.corp.test/

And a wrong system clock makes valid certificates look expired, because curl checks validity against your local time. Run date before blaming the server. I’ve seen this one on a fresh VM more than once.

The option to refuse

--insecure (short form -k) turns both checks off. It “fixes” every error above by ignoring the problem. That’s exactly why it’s dangerous. It also ignores an attacker sitting between you and the server.

Don’t let --insecure become normal in scripts. A script that always runs with -k has given up authentication forever, and nobody will remember why it’s there. Fix the hostname, the trust store, the clock, or the chain instead. Every failure above is diagnosable, and the fix keeps verification working for every future request.

Try it: run curl https://wrong.host.badssl.com/ and read the error. Then run it with -v and find the exact * line where the hostname check fails.