My personal take on this is that with easy automation wildcard certificates simply shouldn't be used any more.
In the past one reason for wildcards was that it's too annoying to request certs for each subdomains. With automation this reason goes aways.
The other reason is that you can have "secret hostnames". But if your security relies on secret hostnames that's a bad idea to begin with. You still leak the hostnames to the DNS and as long as we don't have ubiquitous DoH+ESNI also to the network.
Wildcard certs on the other hand have certain risks. If you have a vulnerability in the TLS stack on subdomain1.example.org that may compromise the security of subdomain2.example.org if they share the same cert.
You have a .example-usercontent.com wildcard certificate for domains like user-1234.example-usercontent.com and you have millions of users. A wildcard certificate is appropriate because:
* LetsEncrypt rate limits are a thing
* The domains exist to leverage origin sandboxing in browsers, but are served by the same infrastructure. It's not more secure (but it is more complicated) to have more certificates here.
Generally, the assumption that two subdomains are served by independent infrastructure is often wrong. Think of things like blogger.com/blogspot.com. So the concern about compromising keys doesn't really apply.
Sandstorm.io serves each session of each document on a different subdomain, which yes, isn't an all-around "secret hostname" (access control is not managed solely via this strategy, of course), but it defeats a lot of possible dangers or ways to tamper with an app.
It would be extremely prohibitive to have to request a certificate for each session of each access to a document, before even discussing the rate limits of Let's Encrypt.
I've used wildcards a lot for securing internal servers. Have a public-facing "internal.my.domain", get a wildcard for that, and and handle the "internal.my.domain" internally, so we have valid SSL certificates for internal services, which otherwise is a pain in the ass.
Also, when running something like a kubernetes or openshift cluster, having dynamic ingress/routes is very easy, and offering the ability to your devs to have SSL not only by default but mandatory, with close to zero configuration, is great.
Wildcards can be used to get around problems in managing access to resources in a multi-tenant environment. If you have 10 product teams, and they all serve different products under a single zone, you may need to grant them all access to modify your nameserver as well as be able to create their own certs at will, if they were going to do independent automated certs. But with a wildcard, you simply give them all the same cert and independently configure the nameserver to point the right records at the right ALBs, and now none of them have any access other than to just serve whatever request hits its ALB.
This would be a nice world to live in, but I stand up more domains in a day for review apps than LetsEncrypt will issue in a week. I don’t even have a large engineering org.
It’s 50 certs per week, not very much.
Honestly I’d pay LE happily for a paid tier option; I would love to subsidize this piece of internet infrastructure in return for all the certs I need.
In the past one reason for wildcards was that it's too annoying to request certs for each subdomains. With automation this reason goes aways.
The other reason is that you can have "secret hostnames". But if your security relies on secret hostnames that's a bad idea to begin with. You still leak the hostnames to the DNS and as long as we don't have ubiquitous DoH+ESNI also to the network.
Wildcard certs on the other hand have certain risks. If you have a vulnerability in the TLS stack on subdomain1.example.org that may compromise the security of subdomain2.example.org if they share the same cert.