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.
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.
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.
I can absolutely understand the need for this, but until then with a bit of code and the automated workflow you could make requests for new subdomains on-the-fly.
Not sure if they'll amend their certificate policy or not. My guess is because their process is automated, they want to confine their certificate issuance to specific domains/sub-domains and not wildcards. It mitigates some repercussions in the event of a compromised cert.
Pg. 24 of the Certificate Policy:
For DV-SSL The Issuer DN of a DV-SSL Certificate shall be its Issuer’s subject DN. CAs shall include FQDNs or IP Addresses of the Device in the subject Alternative Name extension. The Subject Alternative Name extension may contain more than one instance of the name form. CAs may include a FQDN or IP Address in the subject DN for backwards compatibility, but this name shall be also included in the Subject Alternative Name extension. Wildcard names are not permitted
The major problem with this is that the IETF validation working group hasn't come up with a definite procedure for deciding what the apex of a domain is, and how to validate control over all subdomains above it yet.
To make the original comment more precise, should not proving ownership of:
<some domain>
be enough to imply ownership of anything under that? i.e., DNS is a hierarchy — right? At the top level (a bit closer to how the original comment phrased it, I'd say that proving ownership of,
<some domain>.<some public suffix>
should prove ownership of all domains under that. To address the specific case of "co.uk", anyone in control of a public suffix[1] should just fail the check (i.e., owning a public suffix does not imply ownership of all subdomains, which I think is correct). Someone with better knowledge of the innards of DNS would have to speak to if the Public Suffix List is good enough here.
Really, why can't I be a mini-CA for my own domain, with only the power to issue certs for the set of domains I actually have control over? (essentially, why can't I get a nameConstraint CA cert?)
[1]: The Public Suffix list is a list of what a human might call a "tld, essentially"; "com" is a public suffix, but so is "co.uk": https://publicsuffix.org
That's definitely what I was thinking of, but it's not entirely suitable as a list of domains not to issue certificates for, unless you're happy to accept you won't be issuing certificates for domains like blogspot.com or flynn.io.