Take the 2-minute tour ×
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:

  • 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.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?
share|improve this question
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. –  James Billingham Aug 4 '14 at 22:11

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

share|improve this answer
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 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

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.

share|improve this answer

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.

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