I'm thinking more that if you create your own CA and trust it as a root CA, you are responsible for the security of that CA - it can be used against you.

This is especially problematic if I want someone else to trust my certs in their browser, I'm asking them to trust any certificate I generate, including google.com, mybank.com, etc.

I don't want to trust your certificates in my browser, even if you invent all sorts of sophisticated technical hoops to jump through I have no reason to believe you actually did all that hoop jumping. Get certificates for the names you want from a PKI we both trust. The only one that's likely to be applicable is the Web PKI, which is what was done in this article.

For some other purposes, where the Web PKI isn't applicable, you might have a solid argument for why people should trust your PKI. But then they aren't trusting certificates in their browser but in some other likely very constrained system that's easier to reason about.

For example I've operated (for past employers) a service that was available over HTTPS to a handful of insurance and financial outfits using mutual TLS. I'd issue client certificates for them, and then they'd use their private key and their certificate to access the service over HTTPS. In that case I ran the CA, and so they're trusting me. But only narrowly to identify customers of the service I run, so it's not tricky to reason about.

Now, technically you could use certificates from Let's Encrypt as client certificates, they have the right EKU for that purpose but then your identity has to be an Internet FQDN and you need new certificates every ninety days, which sucks. So although I'd have accommodated a paying customer who firmly insisted on doing that, none of them did.

Yes, I generate a client cert and give it to you, that's not a problem - you aren't trusting the cert at all.

I can secure my servers with my own CA, again that's fine - I trust myself.

If you want to verify my servers signed from my CA though you would need to trust my CA.

Currently that means you would need to import my CA's root certificate. That's bad, it's also the way many corporations work, I've had third party suppliers try to get me to trust their own internally generated root certificates too.

A better solution would be for the user to be able to import a root certificate for use for a set purpose. I'm happy to take foobar inc's certificate to authenticate *.foobar.inc, but not to trust anything else.

For some reason browsers don't allow that - it's all or nothing.

> For some reason browsers don't allow that - it's all or nothing.

Absolutely. Name constraints. It's in the spec, but no one seems to implement it. This would fully make PKI useful. Typing x509 certificate (validation) to a delegated ___domain would allow people to import Root CAs from a variety of places while compartmentalizing security.

Right now, if you trust a Root CA cert, you trust any ___domain it signs. This has been a glaring problem for years. I never thought we'd have cheap certs for everything and LE came along and blew my mind.