168

We have a wildcard SSL certificate for *.domain.example, and have a website with sub1.sub2.domain.example.

Safari 4.0.4 on macOS pops up a certificate error(presumably because of wildcard interpretation), while Safari 4 on Windows does not.

Also IE8 behavior is mixed at best, some IE8 display the certificate error and some do not.

What causes this strange behavior on Safari and IE?

Stephen Ostermiller
  • 23,933
  • 14
  • 88
  • 109
porto alet
  • 1,895
  • 2
  • 14
  • 16

3 Answers3

218

A wildcard SSL certificate for *.example.net will match sub.example.net but not sub.sub.example.net.

From RFC 2818:

Matching is performed using the matching rules specified by RFC2459. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.example matches foo.a.example but not bar.foo.a.example. f*.example matches foo.example but not bar.example.

Stephen Ostermiller
  • 23,933
  • 14
  • 88
  • 109
Elias Torres Arroyo
  • 2,562
  • 1
  • 14
  • 9
  • 5
    @Chris I don't think so, there are various technical factors that restrict such rule and forced Certificate authorities to develop security certificate accordingly. –  Oct 08 '12 at 05:20
  • 57
    @sophie various technical factors, like someone realized it's more profitable to sell infinity certificates than to allow 1 certificate to cover every single scenario to infinity. – Chris Marisic Oct 08 '12 at 13:06
  • 2
    @ChrisMarisic Respectfully, that's silly. If that were the case, what would be the point of certs in the first place? – Lyndsy Simon Dec 06 '12 at 21:42
  • 4
    See https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf slide 91 for a possible security threat with wildcard certificates. Also see https://media.blackhat.com/bh-ad-10/Hansen/Blackhat-AD-2010-Hansen-Sokol-HTTPS-Can-Byte-Me-slides.pdf slide 38. – Carl May 06 '14 at 00:56
  • 5
    @user1602478: what are those technical factors? – iconoclast Jun 19 '14 at 00:07
  • 1
    This was clarified in RFC 6125 Section 6.4.3. Checking of Wildcard Certificates – sdaffa23fdsf Jul 28 '15 at 16:38
  • @MartynChamberlin you should be happy, some questions aren't just closed, they're locked with highly misleading information. Good luck resolving your issues then... – Eamon Nerbonne Nov 02 '15 at 14:20
  • 6
    can you have `*.*.example.com` to secure first and second level sub-domains? – Shane Rowatt Jan 08 '16 at 04:27
  • We decided to set up a brand new subdomain under our main brand domain and needed to set up static.website.brand-name.co.uk so that we could serve content from a cookieless domain - but that's out the window now since SSL isn't going to work with it. – Liam McArthur Feb 15 '17 at 13:21
  • 1
    @iconoclast There are none, `*.domain.gTLD` is smaller and faster to match all subdomains than `*.domain.gTLD`+`*.sub1.domain.gTLD`+`*.sub2.domain.gTLD`, etc. It's like the way the cable companies tell you they aren't legally allowed to sell cheap residential service to businesses or the way banks say they legally have to charge a fee if you overdraft the account: while it's true they lobbied to make it that way. That isn't to say SSL certs are entirely a scam, CAs have a purpose and there is some overhead, but anything more than $30/year for a whole-domain wildcard SSL cert is a scam. – CoryG Mar 20 '17 at 04:13
  • 1
    @Carl that attack on p91 depends on finding punycode chars which resemble ? and /, at which point finding one which looks like a dot is no stretch. Punycode homograms are a bigger problem than just *.*.x support, I don't think this is a valid solution. – hraban Jan 30 '18 at 10:49
  • @Carl to add to hraban, in the first case it's not the possession of a wildcard certificate that makes you vulnerable, but rather that someone else can get a wildcard certificate that has homograms. In the second case, yes, risks are increased, but this attack is only possible because the server doesn't check its own hostname (which it should!). – bchurchill Dec 18 '18 at 07:32
  • @ShaneRowatt said "can you have *.*.example.com to secure first and second level sub-domains?" I can tell you that AWS Certificate Manager does not allow you to request those kind of certificates. – Bruno Bronosky Apr 23 '19 at 15:56
  • 1
    @BrunoBronosky Whilst double wildcard certs like ```*.*.example.com``` are not allowed I've found that you can get a multi-domain wildcard certificate, where you can add multiple domains or subdomains up to 4kb in text which gives you anywhere up to 250 domain names depending on domain name length. – Shane Rowatt Apr 25 '19 at 04:13
82

If you need a wildcard certificate that contains *.domain.example sites and also work with sub1.sub2.domain.example or another domain like *.domain2.example, you can solve that with a single wildcard certificate with what is called a subject alternative name (SAN) extension for each of the other sub sub domains. A SAN cert is not just for multiple specific host names, it can be created for wildcards entries as well.

For example, *.domain.example, sub1.sub2.domain.example, and *.domain2.example would have a Common Name of *.domain.example then you would attach a subject alternative name of both *.domain2.example and *.sub2.domain.example. It might depend on the Certificate Authority as to how they would charge you (or not) for the certificate, but there are some out there where this offering is available. Also, SAN is support is pretty widespread in the web browser space. The best real world example of this use, it Google's SSL cert. Go open Google and view its SSL certificate, you will see it works for *.google.com, *.youtube.com, *.gmail.com, and a bunch more where they are listed as subject alternative names.

Stephen Ostermiller
  • 23,933
  • 14
  • 88
  • 109
RobLL
  • 899
  • 6
  • 3
  • 7
    What are examples of CAs who would issue such certificates? – Arto Bendiken Feb 20 '14 at 18:03
  • 15
    So would it be possible to get a certificate for `*.DOMAIN.COM` that has a SAN for `*.*.DOMAIN.COM` (and possibly `*.*.*.DOMAIN.COM`) to cover these sub-subdomains and sub-sub-subdomains? – Simon East Apr 11 '14 at 01:06
  • 5
    @SimonEast not possible. – Nick Jan 24 '17 at 15:21
  • This should be the accepted answer. @Nick, go to https://www.sslshopper.com/ssl-checker.html#hostname=google.com and take a look at the SAN section – Nehal J Wani Mar 10 '17 at 09:44
  • @NehalJWani what should I look for? – Nick Mar 10 '17 at 11:49
  • @Nick In your previous comment, you said 'Not possible'. I am showing to you that it is not only possible, but that is how google is handling it's sub-sub domains. Look at the SANs section http://picpaste.com/pics/Screenshot_at_2017-03-10_17_20_50-OtuDWm2M.1489146789.png – Nehal J Wani Mar 10 '17 at 11:53
  • 1
    I dont see sub sub domains? *.*.domain.com is not possible. *.abc.domain.com - no problem . pls correct me – Nick Mar 10 '17 at 12:47
  • *.*.domain.com is not possible to be issued – Nick Mar 10 '17 at 13:21
20

The wildcard is only applied to the first part (from the left) of you domain. So you'll need a certificate for *.sub2.domain.example

If you meant that you have sub1.domain.example and sub2.domain.example, then it should work.

Stephen Ostermiller
  • 23,933
  • 14
  • 88
  • 109
JAG
  • 1,751
  • 2
  • 16
  • 21