New sub-domains get added daily, so creating a certificate for each isn’t practical.
Our webserver is NGINX and if I could generate wildcard certificates for the following, I could cover SSL for all sites:
*.vic.domain.com
*.nsw.domain.com
*.qld.domain.com
*.sa.domain.com
*.act.domain.com
*.wa.domain.com
*.nt.domain.com
The wild card cert will not cover over the “period”, so, as in your example, you could cover 7 subdomains with 7 wild card certs. But you could actually combine all those wild card entries on to just one cert.
Recall that each cert can hold up to 100 lines (each of which can then also be a wild card entry)
I’m currently using a purchased wildcard certificate for *.domain.com. The problem with that is, the certificate is fine for first level subdomains like vic.domain.com, but not second level subdomains site1.vic.domain.com.
However, if I can do all with one certificate, I don’t have to create multiple virtual servers in NGINX.
I, too, have several subdomains. I do not particularly like wildcard ssl certs to begin with, I prefer to avoid the issue if I possibly can, and I feel that a wildcard ssl cert needs be matched by a wildcard a/aaaa/cname dns record in order to be valid…
Exactly, he’s asking about the future. He even says that they aren’t out yet by saying “When the wildcard certificates become available (Jan 2018 I believe), will it be possible to create a wildcard on a sub-domain like *.vic.domain.com?”
Let’s Encrypt plans to only permit DNS authentication for wildcard certificates, but wildcard records are synthetic so they cannot reliably detect them and there are lots of use cases for wildcard certificates without wildcard records anyway.
You can prevent all CAs from issuing wildcard certificates for your domain by publishing a CAA record with issuewild: ;.
CAA records primarily control which CA can issue a certificate for a domain.
For example, with those CAA records, you would not now be able to purchase a certificate from Comodo, as CA rules would prevent them from issuing it.
Checking by browser or other client software is not required, since obeying CAA records is a mandatory requirement of all CAs. In fact, checking CAA records must not happen on the browser:
If you do ever encounter a counterexample where a CA is issuing certificates that should be forbidden by CAA records, you can report it to the CA, and, if you like, to the security incident contact of your browser vendor. Browsers have shown interest in investigating misissuance of certificates by CAs that they trust and ensuring that corrective action is taken.
Which is really the main the point of all this silliness, because if I were to purchase a certificate from Comodo, I would have to update the CAA records to authorize Comodo to issue a certificate for my domain.
Otherwise, we are trusting the usual mega-corporations, the Turks, the Zionists, the Iranians, the Russians, the Chinese, and all sorts of other folks we don't know to issue certificates for our domains, and we are not the ones surveilling the Internet for forged certificates and TCP/IP misdirections.
