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.
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.
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.
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.
While, true, there are some workarounds, that are, ehm, workaroundy.
1. For _your_ domain, you can have CAA records in your DNS. (That solves it for your domains, not for others, if they do not use CAA)
2. Some CA implementations, like FreeIPA one, allow you to issue certificates only for your own domain. They will refuse to sign a certificate for any other domain.
So while it is not 100% solution, it is 80% one.
> In any case, if you go for an internal DNS provision, make sure you set use-application-dns.net to NXDOMAIN on your internal dns server to override DoH too
Also make sure that the browser honors this. Firefox honors canary domain only when in 'auto DoH' mode, but not, when the user has explicitly configured DoH. From https://support.mozilla.org/en-US/kb/canary-domain-use-appli...:
> The canary domain only applies to users who have DoH enabled as the default option. It does not apply for users who have made the choice to turn on DoH by themselves.