115

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?
Community
  • 1
Nathan Long
  • 2,644
  • 4
  • 21
  • 28
  • 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. – James Billingham Aug 04 '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 `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 Aug 24 '15 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 Aug 24 '15 at 13:37
  • 1
    Found the blog post: http://nickcraver.com/blog/2013/04/23/stackoverflow-com-the-road-to-ssl/ – Ajedi32 Aug 24 '15 at 13:54
  • You don't need three certificates you need multiple subject alternative names within the same certificate. – Ben Aug 24 '15 at 14:45
  • 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 Aug 24 '15 at 14:48
  • @Ben: so has the idea of wildcard certs and single domain certs etc been replaced with one standard cert and any types of defined rules are contained? Or have I gotten my assumption that they're usually one type or another just that only one rule is normally enough? – indivisible Aug 24 '15 at 17:07
  • @indivisible, there is only one kind of cert. Issuers generally charge more for a cert which has a wildcard name, but that's literally just their pricing policy. With a wildcard cert they will usually allow a couple of non-wildcard names in there too, so you should be able to create a cert which does what I suggest. – Ben Aug 24 '15 at 18:50
  • @Ben: Thanks for the answer - it clears up quite a few things about the technical implementations/limits where I'd only found commercial info up till now. If you want to expand your comments into a full answer I'll give you the bounty. Otherwise you can opt to edit your favourite existing answer with the extra details and I'll award the bounty there - your call. – indivisible Aug 25 '15 at 13:00
  • Bruno identified RFC6125 s6.4.3 where it says browsers (specifically browsers rather than general usage) shouldn't accept multiple asterisks in a name. – Ben Aug 27 '15 at 15:40

4 Answers4

77

Theoretically:

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

Community
  • 1
Tom Leek
  • 170,038
  • 29
  • 342
  • 480
  • 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 Mar 15 '15 at 03:54
  • 2
    As I wrote, what RFC 2818 states and what browsers do are different things. Browsers are a lot more restrictive. [RFC 6125](http://tools.ietf.org/html/rfc6125#section-6.4.3) 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 '15 at 00: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 Aug 10 '15 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 Aug 31 '15 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 Aug 31 '15 at 23:51
  • 1
    I wanted to point out that multiple wildcard SAN's is more than theory. Microsoft Office 365 is using it in production at time of writing. (I found that out here http://stackoverflow.com/a/33109589/1695680) – ThorSummoner Aug 25 '16 at 22:23
34

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.

Community
  • 1
Bruno
  • 10,875
  • 1
  • 39
  • 61
  • 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? – voutasaurus Feb 28 '16 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 Feb 28 '16 at 21:30
4

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.

TechNikh
  • 141
  • 1
  • 19
    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 03 '13 at 00: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 Jun 21 '13 at 13:45
1

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.

AJ Henderson
  • 41,896
  • 5
  • 63
  • 110