Will We Be Able to Create Wildcard on Subdomain?


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?

Details as follows.

My problem is we manage hundreds of multi-level sub-domains that look like this:



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:

Will that be possible?

Thank you.

Brett Sh

In short, I think YES

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)

1 Like

Thanks for the prompt reply :slight_smile:

A single certificate would be even better!

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.

Thanks again.

Cheers Brett Sh

Like @rg305 says (thanks!) it will be possible :slight_smile:

Absolutely. You will have to solve DNS-01 challenges for "vic.domain.com", "nsw.domain.com", etc etc.

That's a limitation of all wildcard certificates. You can only have one *, only as the leftmost label, and it only covers one subdomain level.

Hope that helps,

1 Like

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…

I thought Wildcard would only be supported in January '18…

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: ;.


Nope, February 27 :slight_smile:

1 Like

Ah, sorry for my error. But, there will be a public test API by Jan 2018.

1 Like

I hadn’t even heard of CAA records. There is so much new stuff on the market. Anyways, the site https://sslmate.com/caa/ gave me the following data

colmena.biz.    IN    CAA    0 issue "letsencrypt.org"
colmena.biz.    IN    CAA    0 issuewild ";"

Do browsers or other applications even check this before connecting to the ssl-protected server?

1 Like

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.

To some extent this is already happening, and Certificate Transparency will be a mandatory requirement to validate certificates in Chrome from April 2018.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.