0

I been working on and with SSL certificate's for a bit now and my organization is thinking of going with a Wildcard certificate vs the Multi-domain san certificate we have now. What I need to know, is why we should not go the wildcard Certificate route? I know how they work, but I need to sell this to them. I know the advantages and disadvantages.

I have been researching reasons why not to use and the only disadvantage I can really find is the same one every site or person says, " If the .key is compromised then the WCS is". I need a better reason why not to use it then that, because the multi-domain is the same way .key wise. We have and can put steps in place to make this safer.

What we are looking at doing is going from 1 UC Multi-domain with hundreds of SANs and breaking it down with wildcards. this will also be running through a NetScaler SDX 11500. I am not a big NetScaler person but I understand it. If we enabled SNI can we load different certs and keys?

Also do you know of more steps to make it safer. Thanks

Larry
  • 1
  • 1
  • for the latter bit of your question, use reverse proxy ssl load balancers, then use an internal CA between that and your backends. lock that box down, it doesn't need Internet out just ssl in and to your backends – Jacob Evans Mar 21 '17 at 03:51
  • also, if you have a targeted site, such as a payment gateway, use a different cert, if you have a wildcard you aren't required to use it for everything – Jacob Evans Mar 21 '17 at 03:53
  • 1
    @Jacob Evans, What we are looking at doing is going from 1 UC Multi-domain with hundreds of SANs and breaking it down with wildcards. this will also be running through a NetScaler SDX 11500. I am not a big NetScaler person but I understand it. If we enabled SNI can we load different certs and keys? We also will not need an EV. we will not be taking payments. – Larry Mar 21 '17 at 12:51
  • @Larry Netscaler support SNI - if you not using a very old version of it :) – Orphans Mar 21 '17 at 13:09

3 Answers3

1

It's not an either/or unless you make it an either/or, or your certificate reseller insisits on it.

The one catch with SNI is older devices do not support SNI. In the cases that they don't support SNI, they'll fall through to the default binding in on your appliance.

To be more specific, wildcard certificates protect a single level of subdomain, e.g:

*.example.com

will cover

foo.example.com
bar.example.com
autodiscover.example.com

It will not cover

foo.bar.example.com
autodiscover.example.net

So if every domain you need to cover is a single level under a given domain, then a wildcard is certainly an easy and cheap(ish) way to go.

A certificate with SANs allows you to cover as many different domains as you can think of. It can even include wildcards in the SAN, so you could have:

*.example.com
*.example.net
*.example.org

all in the one certificate. Just look at the certificate for this site:

enter image description here

You might want to keep your certificate chain small, so that you can exchange the entire certificate & chain in a single packet. Depending on the length of your certificate chain, this might limit the number of SANs you can put in a single certificate before it goes over the boundary.

As you've correctly pointed out, the same security concerns apply with wildcards or with SANs. It really just comes down to what you need, and what's easier for you to maintain.

If you can support dozens of individual certificates, and are happy to use SNI (and the potential pitfalls), then do that. If you don't want to SNI or don't want to manage dozens of certificates, go wildcard and/or SAN and take the compromises of that instead.

There's no right or wrong answer, there's only what works for you.

Mark Henderson
  • 68,823
  • 31
  • 180
  • 259
  • Of course, even older devices don't support SAN either. Very roughly, browsers from between 2003 and 2006 are likely to support SAN but not SNI. – Mike Scott Mar 21 '17 at 13:26
0

In our environment main problem with wildcard certificate is problems with use it on third level domains, it's not possible at all, e.g. it's ok for *.domain.tld and not ok for *.second.domain.tld.

Alexander Tolkachev
  • 4,608
  • 3
  • 14
  • 23
  • Alexander, I get that and know the issue with the third level. I just need to hear why people are so scared besides the whole compromise issue. we have a get hold on our certs and know where they are located. How has the Wildcard certificate been for your environment? have you had any issues? Are you running a NetScaler? Was the setup ok? What are you doing to make it even safer since all people read is about that they should stay away. thanks – Larry Mar 20 '17 at 18:05
  • @Larry, we don't have any problems with wildcard certificate and haven't think about security issues, our security team doesn't have any concerns about wildcard certificate. – Alexander Tolkachev Mar 20 '17 at 20:11
  • what was the smoking gun that had you team sold on the wildcard? – Larry Mar 20 '17 at 20:26
0

The only problem we have had with wildcard certificates is with Microsoft Lync Server 2013 which didn't support wildcard certificates for some of the services as clients used certificate verification that didn't work with wildcards. I'm not sure if the latest version of Lync 2016 (aka Skype for business) still has this restriction or indeed why the restriction is in place - presumably some security measure

Phil
  • 3,168
  • 1
  • 22
  • 29
  • What we are looking at doing is going from 1 UC Multi-domain with hundreds of SANs and breaking it down with wildcards. this will also be running through a NetScaler SDX 11500. I am not a big NetScaler person but I understand it. If we enabled SNI can we load different certs and keys? We also will not need an EV. we will not be taking payments. – Larry Mar 21 '17 at 12:52