There are more benign uses too - many organisations run an internal PKI, and installing their root CA prevents employees' browsers from displaying warnings about untrusted certificates when accessing internal web apps/sites.
You might be able to make intranet.company-name.tld and have a parking page on the company-name.tld and use that to get a wildcard cert that can be used for the internal pages.
However you would have a single wildcart cert + key that would need to be placed on thousands, or tens of thousands, of machines, by hundreds of staff is dozens of departments.
It would be meaningless.
I can prove ownership and then receive a wildcard certificate for *.internal.company.com, usually by a TXT record or similar (lets ignore EV certs for now), however that certificate isn't an intermediate certificate which is limited to signing new end certificates for blah1.internal.company.com, but wouldn't be able to sign for blah1.not.company.com.
I'm no SSL/TLS expert by any means, so please let me know if I'm wrong and it is fairly easy to get intermediate certificates that are domain name limited - x509 constraints are apparently flakey.
I don't think it's a bad use. When I logon to my SAN or UPS web interfaces, I don't want to type https://ups01.publicDNSdomain.com, and visit a site with a CT logged certificate. It's an absolutely internal thing and every Active Directory domain already has an (ideally) non-externally resolved DNS domain setup for use. You've already got an internal CA and deployed your own root because there's a series of Microsoft services that work best this way, so it makes a lot of sense to continue to use rather than trying to introduce Lets Encrypt in this scenario.
You don't have to serve that website publicly or even set up DNS records. You only need to set up DNS verification to serve one public TXT record for letsencrypt. Everything else could be internal. Letsencrypt certifies that you own domain. You can do anything with that domain.
Sometimes you don't want to make that information public though. For security (you don't want to publish your whole tech stack information) and secrecy (you don't want to publish registration of halflife3.internal.valve.com).
Wildcard certs are a security ops nightmare. You really don't want to throw the private key for that around to every small project, and you need some good, automated way of rolling them across multiple services. Doable, but if you can avoid this, it's a better to avoid.
This 100x - in just about any organisation of any size, if you use a single wildcard cert for all internal services, then it's inevitable that the private key will end up in the hands of an employee that shouldn't have it.
Well, it's unnecessary work to install and maintain that internal CA. Keeping CA key safe is very important, because leaked key might lead to your internal connections to, e.g., Google be compromised, so it's like keeping a bomb inside your building. If you already have that internal PKI, you can use it, sure, but I still think that it's a bad idea to use it only for internal websites.
> Letsencrypt solves any need for legitimate certificates.
... unless you want any private keys to be personally signed and or generated by bob & alice over in security after checking some boxes in an internal audit form, or any other number of company-internal schemes involving signing and encryption of business-specific data
You're generating private key securely. You're generating CSR which contains public key and signed by that private key and now you need to move that CSR from private location to a public location. But that's not bad, it does not contain anything that could be compromised and your private key is kept safe. Then you're using letsencrypt to issue that certificate using that CSR and keep using that CSR (it does not expire) to renew certificate. All that time private key is kept in safety and is only used by your webserver.
Letsencrypt allows you to generate legitimate certificate for internal websites without any compromise on security.
The only use-case that's not possible with Letsencrypt is to issue certificate for IP address.
Letsencrypt only issues certs for publicly accessible hosts. If you've got a bunch of intranet servers / REST services / whatever that are firewalled from the public internet, you're out of luck.