Sign up ×
Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

I'm working on a web site with a several levels of subdomains. I need to secure all of them with SSL, and I'm trying to determine the correct certificate strategy.

Here's what I need to secure:

  • Any combination of (These are US states.)

My understanding is that a wildcard certificate can only cover one "level" of subdomain. According to RFC 2818:

Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., * matches but not f*.com matches but not

What I think I need is the following certificates:

  • *, which will match, for example,, (Though I'm not clear on whether * matches by itself.)
  • * to match,, etc. I will eventually need 50 such certificates to match all the states, once our site expands to serve them all.

My questions are:

  • Is this scheme correct? In the scenario above, if a user visits, will they get the certificate for * or for *
  • How can I ensure that users see all of these subdomains as legitimately owned by us? For example, if a user visits, then, and those are different certificates, will they get a warning? Is there some way to assure their browser that these certificates share the same owner?
share|improve this question
Aside from the exact topic of this question, it's worth noting that you could also do, which would be pretty user friendly. –  James Billingham Aug 4 '14 at 22:11
To answer your very last question - the browser will verify that the certificate matches the site you're on, and that it's issued by a trusted CA, and that it's valid at this point in time. Going from to won't trigger any warning, just as following a link from to won't. The browser does not care that there's a subdomain involved. –  Jenny D Aug 24 at 12:21
This sounds very much like one of the problems Stack Exchange is having with setting up TLS on their site. –  Ajedi32 Aug 24 at 13:37
Found the blog post:… –  Ajedi32 Aug 24 at 13:54
You could cheat and use (dash) instead of dot. Then you would have only one level and would only need a single wildcard * as well as as subject-alternative-names. –  Ben Aug 24 at 14:48

4 Answers 4


  • a * matches exactly one level (hence * does not match
  • but you can have several * in a name

Hence, if all SSL implementations faithfully follow RFC 2818, you just need three certificates, with names:

  • *
  • *.*

and, if the implementations are really good at sticking with RFC 2818 and the intricacies of X.509, you could even use a single certificate which lists the three strings above in its Subject Alt Name extension.

Now, theory and practice perfectly match... in theory. You may have surprises with what browsers actually do. I suggest you try it out; some example certificates can be created with the OpenSSL command-line tool (see for instance this page for a few guidelines).

share|improve this answer
This does not seem to work with the "Subject Alt Name" extension. is not covered with a cert for, that also has * and *.* as alternate name. It appears to be that only the first wildcard is being considered. Both Firefox and Chrome complain. I am using nginx as a server. –  blueyed Mar 15 at 3:54
As I wrote, what RFC 2818 states and what browsers do are different things. Browsers are a lot more restrictive. RFC 6125 is closer to what actually happens in practice. (The server species does not matter here, only the certificate contents and the Web browser.) –  Tom Leek Mar 16 at 0:00
I'm seeing the same as @blueyed, browsers complain if certificates have multiple subdomain wildcards ala *.* It doesn't seem like having more than one subdomain wildcard is possible without browsers complaining. –  Mahn Aug 10 at 20:59
Near as I can tell, RFC 2818 doesn't talk about wildcards, beyond, "Matching is performed using the matching rules specified by [RFC2459]."; RFC 2459 is obsolete. Following the updates, all you get is "the semantics of subject alternative names that include wildcard characters are not addressed by this specification. Applications with specific requirements MAY use such names, but they must define the semantics." That spec seems to be RFC 6125, which states in a rather round-about fashion that double wildcards are illegal. It appears double wildcards are illegal both in spec, and in practice. –  Thanatos Aug 31 at 23:22
The part about RFC 2459 is not about wildcards; RFC 2459 (and its successors, RFC 3280 and 5280) does not talk about wildcards. Wildcards are described by the sentence that follow in RFC 2818: "Names may contain the wildcard character * which is considered to match any single domain name component or component fragment"; that sentence is not an explanation of RFC 2459 rules, but an additional matching rule. –  Tom Leek Aug 31 at 23:51

RFC 6125 is quite recent and not implemented by everyone, but it tries to clarify some of these issues. It gathers the identity specification in RFC 2818 and RFCs of other protocols. I would suggest adhering to RFC 6125 if you can. The relevant sections for wildcard certificates are 6.4.3 and 7.2 (which discourages the use of wildcard certificates, in fact).

It's not clear from your question whether you want to run a single web server (or at least be able to run it all behind a single IP address), or if you're able to have a certificate per site (and thus an IP address per site, since SNI is not very well supported in general).

You could have a single certificate with multiple Subject Alternative Names (SANs). The problem comes from the case with two wildcard labels, which may not be clearly specified (*.*

If the double wildcard works, a certificate with these 3 SAN DNS entries should work:

  • *
  • *.*

However, since it might not work (depending on the client's implementations, which are probably not under your control), and since you can list the 50 states, you could have 52 SAN DNS entries:

  • *
  • *
  • ... (one for each state)

How can I ensure that users see all of these subdomains as legitimately owned by us? For example, if a user visits, then, and those are different certificates, will they get a warning? Is there some way to assure their browser that these certificates share the same owner?

This is a tricky question, since it depends on how familiar the users are with the certificate verification process. You could get an Extended Validation certificate (although I think wildcard EV certificate are probably not allowed), which would give a green bar. This would give some "ownership" label in most browsers. After that, browser's interfaces themselves can be confusing (e.g. Firefox's "which is run by (unknown)" in the blue bar, which doesn't really help either way). Ultimately, the users could go and check within your certificate to see to which SANs the certificate was issued. However, I doubt many will do this and understand what it means.

share|improve this answer says

Even more, DigiCert WildCard ssl certificates are unique in allowing you to secure ANY subdomain of your domain, including multiple levels of subdomains with one certificate. For example, your WildCard for * com could include as a subject alternate name.

share|improve this answer
What a CA says in its marketing material should be interpreted with caution. How names are verified doesn't depend on them, but on the client implementations and how they follow the specifications. When read closely, this sentence could mean that they'd issue a cert with a SAN for * and another SAN for, not necessarily that the cert will allow any subdomain at any level once issued. –  Bruno Apr 3 '13 at 0:31
I just had a chat with them about this. Bruno is right - with a wildcard cert they let you add up to 10 single names, but you can also purchase extra wildcards and add them as SAN names. They will also issue duplicates of the original cert and you can add another set of names to that at no extra cost, though that would need an extra IP. They provide a web UI for adding names and reissuing is free of charge. They can allow up to 30 names per cert on request. Sounds like a nice service, similar to what AJ Henderson says StartSSL do. –  Synchro Jun 21 '13 at 13:45

You could either use a wildcard cert or you could also make use of a certificate with alternate domain names. Personally, I use a certificate from StartSSL which allows me to have all of my domains listed on a single certificate. I have something like 10 wildcard domains and 15 some other ADNs all on the same certificate so that I can use SSL across the sites I have hosted on my server.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.