Keep TLS verification enabled

For HTTPS, curl verifies two things about the server’s certificate: that it chains to a trusted authority and that it matches the requested hostname. Both checks protect the server identity. The chain check proves someone trusted vouched for the certificate. The hostname check proves the certificate was issued for the name you asked for, not some other site. Skip either one and encryption still happens, but you 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 verification 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.

A successful check means the requested name and trust chain passed for this connection. The subjectAltName ... matched line is the hostname check happening, and verify ok is the chain check passing.

When verification fails

A failure looks like this:

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

The important part: this error is information, not an obstacle. Each cause has a real fix. A hostname mismatch means you’re connecting to a name the certificate doesn’t cover — fix the URL or the certificate. An incomplete chain means the server forgot to send an intermediate certificate — fix the server config. 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 validity is checked against your local time. Check date before blaming the server.

The option to refuse

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

Do not normalize --insecure in scripts. A script that always runs with -k has silently given up authentication forever, and nobody will remember why. Fix the hostname, trust store, system clock, or certificate chain instead. Every failure above is diagnosable, and the fix keeps verification working for every future request.