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:

  • foo.com
  • www.foo.com
  • Any combination of city.state.foo.com. (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., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com.

What I think I need is the following certificates:

  • *.foo.com, which will match, for example, foo.com, www.foo.com. (Though I'm not clear on whether *.a.com matches a.com by itself.)
  • *.ny.foo.com to match new-york.ny.foo.com, buffalo.ny.foo.com, 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 ca.foo.com, will they get the certificate for *.foo.com or for *.ca.foo.com?
  • How can I ensure that users see all of these subdomains as legitimately owned by us? For example, if a user visits foo.com, then mountain-view.ca.foo.com, 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?
  • 6
    Aside from the exact topic of this question, it's worth noting that you could also do foo.com/state/city, which would be pretty user friendly. Commented Aug 4, 2014 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 foo.com to bar.baz.foo.com won't trigger any warning, just as following a link from foo.com to bar.com won't. The browser does not care that there's a subdomain involved.
    – Jenny D
    Commented Aug 24, 2015 at 12:21
  • 1
    This sounds very much like one of the problems Stack Exchange is having with setting up TLS on their site.
    – Ajedi32
    Commented Aug 24, 2015 at 13:37
  • 1
    Found the blog post: nickcraver.com/blog/2013/04/23/…
    – Ajedi32
    Commented Aug 24, 2015 at 13:54
  • 5
    You could cheat and use city-state.foo.com (dash) instead of dot. Then you would have only one level and would only need a single wildcard *.foo.com as well as foo.com as subject-alternative-names.
    – Ben
    Commented Aug 24, 2015 at 14:48

4 Answers 4



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

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

  • foo.com
  • *.foo.com
  • *.*.foo.com

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).

  • 5
    This does not seem to work with the "Subject Alt Name" extension. foo.bar.baz.example.com is not covered with a cert for baz.example.com, that also has *.baz.example.com and *.*.baz.example.com 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
    Commented Mar 15, 2015 at 3:54
  • 2
    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
    Commented Mar 16, 2015 at 0:00
  • 1
    I'm seeing the same as @blueyed, browsers complain if certificates have multiple subdomain wildcards ala *.*.baz.example.com. It doesn't seem like having more than one subdomain wildcard is possible without browsers complaining.
    – Mahn
    Commented Aug 10, 2015 at 20:59
  • 2
    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
    Commented Aug 31, 2015 at 23:22
  • 1
    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
    Commented Aug 31, 2015 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 (*.*.foo.com).

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

  • foo.com
  • *.foo.com
  • *.*.foo.com

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:

  • foo.com
  • *.foo.com
  • *.ny.foo.com
  • ... (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 foo.com, then mountain-view.ca.foo.com, 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.

  • This was 4 years ago. What is the state of client support for multiple wildcard depth? Does anybody know about this for any of the major browsers: Chrome, Safari, Firefox, IE, Edge, Opera? Commented Feb 28, 2016 at 21:17
  • 2
    @voutasaurus As far as I know, this is still valid (RFC 6125 has not even been fully implemented in all clients). I don't think anyone tried to consider multiple wildcard levels as a feature to add to any spec.
    – Bruno
    Commented Feb 28, 2016 at 21:30

http://www.digicert.com/welcome/wildcard-plus.htm 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 *.digicert.com com could include server1.sub.mail.digicert.com as a subject alternate name.

  • 20
    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 *.digicert.com and another SAN for server1.sub.mail.digicert.com, not necessarily that the cert will allow any subdomain at any level once issued.
    – Bruno
    Commented Apr 3, 2013 at 0:31
  • 5
    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
    Commented Jun 21, 2013 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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .