That would mean I can issue a valid, trusted worldwide, certificate what will work on your internal site.
Using public domains for internal sites are the way to go in my opinion. As long as you pay the bills you have guarantee that you control your domain. You can issue any kind of certificates and so on. If you have a nice naming scheme you won't leak that much info in then Internet. A lot of companies I know does that, by the recommendation of security teams (due to issues with using .local or .example.com domains).
> If you have a nice naming scheme you won't leak that much info in then Internet.
IME even if you leak the name of every internal service, you're still more secure than training all users to ignore certificate errors, which is what internal CAs do 85% of the time.
Maybe I was unclear, but I was wishing for a situation where the Name Constraint extension was wildly enough used that LE would issue scoped sub-CA certs for *.whatever.yourdomain.com, which I hold the private keys to.
But yes, I agree with your larger point. However, "nice" naming scheme might conflict with "secure" naming scheme. E.g, perhaps admin-{not-yet-released-product-line}.acme.com is the most resonable domain name, but it would be unsuitable if it was publicly announced via CT logs.
Any way, having the domains in the CT logs, and naming them considering that is probably a tradeoff worth making.
Using public domains for internal sites are the way to go in my opinion. As long as you pay the bills you have guarantee that you control your domain. You can issue any kind of certificates and so on. If you have a nice naming scheme you won't leak that much info in then Internet. A lot of companies I know does that, by the recommendation of security teams (due to issues with using .local or .example.com domains).