It can be tricky to get self-signed certificates put into all the various places where they need to be. OS level certificate stores, browsers, mobile devices, curl, python/requests, VPN clients, etc. There's always some weird exception case.

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.

It appears to me the issue is browser warning dialogs that imply it is always very dangerous. There should be either more context explained in those dialogs or a recognition of/mode for sites that are supposed to be self signed.

There is a long history to this. The original browser warnings were along the lines of your suggestion. Then it was discovered that regular users just clicked through the warning when an attacker MITM'ed their bank. There followed decades of making the warning ever more scary sounding and ever more difficult to bypass.

Where does responsibility lie here? Is there a mechanism for users to state trust towards their org's sysadmin instead of a global authority? If there isn't, what is the problem preventing this in the long history you mention?

(Untested idea) I'd suggest creating your own Root CA with an expire-date far in the future. Install it's public key as a trusted certificate and all derived certificates should not prompt any issues anymore

I did this on my workstation. I used it for a short while. Then I realized that I was actually putting a thing into the world that circumvents the entire security infrastructure of the world. Then I needed to do it for a server. Local only. Never production.

Then I thought, WTF am I doing?. I realized that I was making computers that would circumvent the world's security apparatus. Of course it won't hurt if I make no errors of practice or judgement but, am I really smart enough to handle highly radioactive material.

I ripped it all out. It makes me shudder thinking about it.

Then far in the future, when your own Root CA expires, then there comes all the trouble to update all the services/devices to trust the new Root CA.

This becomes a nightmare, when the original admin in the org is gone long times ago.

Please don't. I've been in orgs doing this and it sucks. There seems to just be to many edge cases, and to many custom scripts for setup.

That's not untested insofar as that's how I've always seen self-signed certs managed in an org.