It’s known that from the RFC 2606 that .test and others should be used for development purposes. It would be cool to have valid (in the chain of trust) CA certificate for these reserved TLDs to generate any kind of a certificate (ie. wildcard, not necessary EV).
These TLD domains are not recognized by any public DNS server in the well-configured network, so there’s no possibility to come up with a collision that could possibly do damage. Also it’s pain in the butt to get self-signed CA with these TLDs into Google Chrome as well as it’s a potentially unsafe.
More like a discussion (and maybe a feature request). So if I understand it correctly (reading Symantec Blog Post ), CA/B Forum said that public SSL certificates for public TLD can not be signed by the public CAs for private/internal domains.
Okay, then can Let’s encrypt become a private vendor as well? Even for a small yearly fee? I have looked up Symantec’s website, but I don’t see how much they ask for Private CA.
Any certification authority which chains to publicly trusted root CAs is considered a "public CA" (even if it is subCA only for single company) and is bound by CA/B Forum rules. "Private CA" would require the same amount of setup as self-signed CA - it won't be trusted by any kind of software by default.
Okay, so screw the “public/private” nonsense then. Thanks for clearing that up.
You have TLDs that are reserved for internal/local use by the RFC which I stated above. Having an optional local CA (as an opt-in) signed by intermediary CA like LE, or Symantec would not require any additional “self-signed root CA” and “CA” key deployment. And it would be secure by default, if a dev would use it.
I mean, the local CA would sign certificates only for these specific TLDs.
It’s very simpel actually: whatever clever scheme you might think of, every non-publically TLD will never be signed by a “publically trusted” (i.e.: included in the trusted certificate store of browsers) CA.