[kodablah]

While I too would like to see wildcards, doesn't the fact that you can programmatically obtain a cert for a subdomain obviate most of the wildcard needs? Sure it's a bit more difficult but if your service has some form of sorts to make a subdomain work for a specific word, surely it can request the cert at that time. Having said that, obviously keeping track of only one cert and not having to build this into your apps is much more preferred.

[carterehsmith]

This comes up when you are running a multi-tenant app with many tenants; github.com is a good example. You can sign up as "dude.github.com" or "me234.github.com" and so on. So, Github can either a) obtain wildcard SSL cert for "*.github.com" once, and then present it to tenants, and control access with the "domain" property of the cookie, and don't worry about SSL cert until next year's renewal time, or 2) apply to some authority for XXX.github.com every time the new tenant signs up. Well, 2) makes you reliant on "some authority" every time new customer signs up, (hopefully many times a day!) which is not so very good IMHO. Just my 5c.

[dingaling]

Without wildcards you can't use the automated tool to pre-provision new servers, for example.

Say 1.example.com is in production and is to be swapped for new1.example.com which is in staging.

new1 can't obtain a useful cert from Let's Encrypt until it becomes 1 in Internet-facing DNS. So you have a service discontinuity whilst moving 1 -> old1 and new1 -> 1 and then applying for the cert.

I appreciate that the set of people managing such issues probably aren't the target market ( they also won't be running an as-root tool to make automated changes on their edge servers... ) but it's an example of why wildcards are so useful.

[inopinatus]

Not all subdomains are known in advance - DNS has wildcards too.