Yeah, I think OP probably mostly does web development through the browser, where there’s just one trust store to worry about.

As soon as you need some automation involving backend services or even just curl and some scripts, this gets tougher. (And please please don’t use `curl -k` to disable checks… if such scripts accidentally make their way to production, you may as well not use TLS at all.)

About the -k: why?

A certificate has two main functions: identity of the server and encryption. Not checking the chain leaves you with encryption, which is likely what your need.

A self-signed certificate is as good as any other when it comes to encryption.

If you're in a situation where encryption matters to you, you're in a situation where the identity of the remote end ought to matter to you as well. If someone's able to snoop the traffic between you and the remote end, it's dangerous to assume they won't also be able to MITM you.

A self-signed certificate provides an identity the same way as a CA-signed one. The only difference is that it is in a CA chain.

You may trust the CA enough to not check further, but if you want to make sure that the endpoint you are talking with is the one you expect, you should check the identity of the certificate on the server. And it is the same for a self-signed certificate as from a CA-issued one.

`curl -k` doesn't do any of that. It just connects via TLS and does no checking whatsoever on the remote server's identity.

And what you're saying about CA certs has no resemblance to reality. People don't look at certs by matching their public keys exactly to what they expect... they trust certificate authorities to make that determination for them. But again, `curl -k` does neither so I don't think your point applies regardless.