Root Causes 110: Single-domain, Multi-domain, and Wildcard SSL Certificates

Hosted by

Fellow

Original broadcast date

August 6, 2020

When you obtain an SSL certificate, you can choose between single-domain, multi-domain, and wildcard certificates. Join our hosts as they explain the different domain spaces available with TLS certificates and the pros and cons of each approach.

Podcast transcript

Lightly edited for flow and brevity.

TCTim CallanToday, we want to talk about the different what I would call domain scope choices that are available for SSL certificates and what I mean by domain scope is I mean what’s the extent of the domain names that a single certificate can cover and really in this is world there are – nomenclature-wise there are three choices. People talk about you get a single domain certificate, you get a multi-domain certificate, and you get a wildcard certificate and I think we should define those and we should discuss how they can be used well and maybe how they are misused and what the pros and cons are of each.

Jason SorokoSure, Tim. Hey, let’s get right down to real-world scenario of I’m running a website, I’ve got, it could be a complex set of pages. It might not be. But probably if you are contemplating using a multi certificate of some kind or a wildcard certificate you probably are using different subdomains.

TCTim CallanYes.

Jason SorokoAnd the certificates would then obviously cover those subdomains with a single certificate, which is awfully handy if you are quite often changing your subdomains perhaps because you don’t have to then get another certificate for every different subdomain that you are creating. So, there’s definitely advantages to it, Tim, but there’s disadvantages.

TCTim CallanRight. So just so everybody is aware who is listening to this, from the SSL world each subdomain is its own domain. So yoursite.com is not the same thing as shop.yoursite.com. Those are separate and so, originally, back in the very early days you got a cert for each. You got a cert for yoursite.com and a cert for shop.yoursite.com and the industry realized that this made things difficult in a lot of ways especially if you wanted to be able to serve these different domains up from the same server and so we invented the quality of a SAN, a subject alternate name. And so, the basic name, we call it an FQDN, a fully qualified domain name, is the basic domain name that the cert has, and every cert must have a FQDN on every SSL cert or it’s not an SSL cert. Right? It’s not connected to a domain name. But you can connect that to other domain names and you do that using the “SAN field”. In principle the number of SANs you can have is very high. So sometimes people call these SAN certs or sometimes they call them multi-domain certs. We call them multi-domain, is our product name at Sectigo, but a lot of people just all of them “SAN certs”. We don’t cause it’s a little bit of a misnomer. But, you know, the number of SANs you can have in principle is very high and that means that in principle you could have lots of different domains and then the other thing about it is these don’t even need to be all the same subdomains. They are just SAN fields. So, in principle, I could have mysite.com as the FQDN and then I could have shop.yoursite.com in a SAN. So that makes it even more complex. And so, you know, kind of at a high-level definition we say a single domain cert is a cert that’s just for mysite.com, a multi-domain cert is a cert with SAN fields that expand it to other domains beyond that and then there is what is called a wildcard and how a wildcard works is a wildcard covers the main domain name, mysite.com, and all subdomains. And the way we right that down is *wildcard.mysite.com. And that cert will work for the top level, just good old-fashioned mysite.com and it will also work for any subdomain on mysite.com and so those are the three basic definitions that people use when they talk about, again, what I’m calling domain certs or certificate sites based on domains although it gets a little more complex than that and we’ll probably explain that a little later in this podcast. So, with that kind of groundwork, you were gonna say there are some pros and cons, Jay?

Jason SorokoYeah. There’s some pros and cons, Tim. I guess the worry, if you want to just address it, is that these kinds of multi-domain certificates that have multiple SANs described as you said, as well as wildcard certificates are potentially being overused right now.

TCTim CallanYeah. Yeah. That’s absolutely the worry. Is you say, oh goodie, I’m gonna stuff 300 SANs into this cert and that way instead of having to think about 300 certs I have to think about one.

Jason SorokoYeah. You are right, Tim. So, you know, in terms of security – let’s back up all the way to the beginning – in terms of security, quite often we like to think about things in terms of whitelists and blacklists. Like, for example, we’ve talked about the CAA. We’ve talked about the CT logs. It’s interesting in that those are essentially forms of whitelisting that we have in this industry where you basically are explicitly stating here are the CAs I want to be able to deal with and if a certificate gets issued from something else don’t allow it. And with the CT logs, it’s visibility into what has been issued in my domain and so those are really handy and good things. The problem with wildcard and the problem with multi-domains is, and wildcard perhaps especially is that, think about, Tim, how many times you’ve read about site compromises. It’s unfortunately very common and for various reasons and perhaps that’s several podcasts into itself but if you cannot yourself track the number of subdomains that perhaps are being created maliciously for purposes of phishing attacks or something else, those maliciously created subdomains are going to be inherently trusted because of a wildcard certificate, for example.

TCTim CallanAbsolutely. I mean one of the benefits of a wildcard certificate is that I don’t have to know all the subdomains that I’m going to use when I issue the certificate. So, if I issue a multi-domain cert, let’s say I’m using four sub-domains. I’ve got mysite.com, shop.mysite.com, cart.mysite.com, and login.mysite.com. Ok. Great. I go and I get a multi-domain cert and I’ve got those four covered and then I wake up one day and I realize that I want to do something new. I want to have a chat function and I want to have chat.mysite.com and all the sudden I have to swap out a cert. It’s one more list of things I need to do. I need to get a new MDC that’s now five big instead of four big. I need to get rid of the old one and put in the new one, right. But if I have a wildcard, I don’t. I just stand up the new subdomain and it just plain works. So that’s killer. If you are an IT Administrator, you like that. It’s one less thing on the task list. It’s one less potential error that is going to prevent your site from going live when you want it to go live. It’s agility. Right? It’s speed to market. All these things are good and that’s kind of a simple example, but what if it’s much, much more complex than that, right?

Jason SorokoYeah. In a perfect world, it’s all good. It’s all good. Why wouldn’t we only use that because then we wouldn’t have to plan. It’s fantastic.

TCTim CallanRight. But it’s also agility and speed to market for the bad guy in the scenario you just described, right?

Jason SorokoThat’s right. So in other words, site compromise where a bad guy is going to set up subdomains without you knowing it and then those subdomains will be trusted inherently because it’s a brand-new, fully-qualified domain name created maliciously that just will be trusted but then of course, Tim, the second half of this is key compromise, which is if that very important key gets compromised, that certificate somehow gets in the hands of somebody it shouldn’t all of the sudden a revocation of that – boy oh boy, the ability for you to have put your feet up on the desk and not have to worry about creating your own subdomains all of the sudden has cost you. So it’s all good in a perfect world where bad guys don’t exist. Unfortunately, that’s not where we live.

TCTim CallanYeah. So, if we have a little thought experiment, you say, well, why wouldn’t you just get one cert and put it on every single server you have and it’s easy to say, well, you wouldn’t want to do that. Well, why wouldn’t you want to do that? Well, there is no granularity there. Right? If there’s a problem, then that problem affects everything you have. The scope is huge. If there is a problem, you don’t know about then somebody has got the keys to the entire kingdom. If there’s a problem, you do know about you have to blow up the entire kingdom. Right? You can’t go and you can’t laser shoot. There’s one cert. I’m gonna replace this one cert and that one cluster or that one server is going to be down until I get that done. Right? That is not available anymore, right? So that’s why we wouldn’t take the same cert and stick it across all our different servers. Well, once you start to get into these scenarios where you are, like you say, overusing wildcards or multi-domain certs that’s what you are doing and so this is, what level is right number of domains? - hugely situational and a lot of it depends on the value of what’s being certified, you know, what’s being covered. A lot of it depends on your organization and how agile you can be and how quickly and accurately you can make these changes and I think a lot of it depends on your risk profile but definitely the more that you extend your multi-domain cert or your wildcard, the more your risk goes up and the more responsibility you are taking to be able to deal with the certificate management needs in an extremely crypto agile fashion and the more responsibility you are taking for the rest of your security to be up to snuff.

Jason SorokoSo, from a pragmatic standpoint, Tim, perhaps what we are suggesting here – I don’t think anybody in the modern age has a static website, just a very simplistic static website and if you have that well then perhaps you don’t have to worry too, too much. In that case, don’t use a wildcard, use a single domain certificate and you are good to go. Or, if you just have one or two or three subdomains go ahead and take advantage of just locking down the fact that those handful of subdomains can be listed in a multi-domain certificate and away you go and you are done. I guess what I would suggest is if you know your structure and the structure is going to be static at least for six months to a year go ahead and use that multi-domain certificate to basically whitelist here are the fully qualified domain names that I’m gonna allow. I won’t allow anything beyond this by just getting a wildcard. In other words, I think, you must ask yourself if you are getting a wildcard, why are you doing it? Are you doing it because somehow the structuring of your website is such that you create brand-new fully-qualified domain names on a daily basis. If that’s the case and that’s really how you do your business, well then, a wildcard is for you, but you have to understand the risks.

TCTim CallanRight. And that’s where the risks kind of go up. I told an incident one of our recent episodes about when we revoked a certificate for a phishing site and the hoster published a Twitter post and they added us and they said, hey, Sectigo by revoking this cert you shut down 300 innocent websites and my response to that is well, why are you using the same wildcard on 300 websites that don’t know each other? And I would propose that that is a perfect example of misuse of that certificate because the risk situation that it created, especially since you are letting people put up content that you don’t even control, they’re just putting up whatever content they put up. The risk situation there is completely untenable. You don’t know what’s gonna happen that is gonna mean that your certificate must be destroyed at any given time and as soon as that happens all of these other sites go down who did absolutely nothing wrong except arguably choosing the wrong hosting provider. So, in that regard, that is misuse for sure.

Jason SorokoYeah, Tim. And there is a few examples of where that’s is used and there is a lot of it out there so let’s call out some of it.

TCTim CallanSure.

Jason SorokoCDNs. If you are a customer of a CDN you might have a CDN certificate - - your origin server might have its own SSL certificate but when you are then broadcast out of a CDN the CDN is going to have its own certificate for you.

TCTim CallanRight.

Jason SorokoAnd it’s very, very common for the certificate used for that for you to be packed with many other subdomains of customers of that CDN, not just yourself.

TCTim CallanRight.

Jason SorokoAnd I’ve seen upwards of over 400 multi SANS within a single certificate which is just outrageous.

TCTim CallanYep. Now again, that CDN feels that they can manage it and feels that they can change out these certs in an automated fashion, you know, multiple times a day if need be and if they can, then I suppose it can work; but, if they can’t, then they can be getting themselves into a bind.

Jason SorokoYeah, sure, Tim. I guess this is exactly it. In a perfect world who cares. Put 10,000. It’s just a technology mechanism but in the world of security, there’s risks and you would never, you know, there’s a lot of things in life where we buy insurance because things go wrong and thinking about a multi-domain certificate as just a no risk scenario for you that’s probably a bit short-sided but, you know, it’s not just CDNs, Tim.

TCTim CallanWho else?

Jason SorokoIt’s any kind of service. You might as a business have training services for your employees, or you might have third-party websites set up for you by other vendors that will create a website on your behalf. They’ll use their main domain, but they will create a brand-new subdomain, you know, mypartner.yourcompany.com. So therefore, it’s not a site that you maintain, you hire out those services, but quite often those services again, when they issue an SSL certificate, they will pack your domain off with many other of their customers and therefore those might be risks that you are not even taking into account. In other words, what are your purchased vendor risks because of their multi-domain SSL certificate usage scenario. What are they doing? Those are questions you might want to ask or in fact, check up on the CT log because it will tell you what you are bound with.

TCTim CallanYes, it will. Absolutely it will. And also, that’s where CAA comes into play. Again, because if you’ve got other people obtaining these certs for your domains and you happen to have put in CAA rules, it’s possible that your CAA rules will conflict with what they normally do. In which case, there could be a deployment hiccup. Since you brought up CAA, that’s another thing that could happen in that scenario.

Jason SorokoThat’s great, Tim. It’s an interesting subject. You know, there’s no clear-cut way of saying what you should or shouldn’t do here but it is to understand your risks.

TCTim CallanYeah, absolutely. And at a high level what happens is you get more flexibility and agility for how to use your systems, especially in complex environments and CDNs are that if you use multi-domain or wildcards but you also increase the risk, not just the likelihood that there’s a problem but more than that, more importantly, the impact when there is a problem tends to go up greatly. So that’s the risk/reward profile you need to think about. The last thing I want to bring up on this topic is – and this is just a reality that happens – a lot of people choose multi-domain certs or wildcard certs simply because they feel that it’s cheaper. They say ahh, I’m gonna need this much of this or this much of that and it turns out it’s cheaper to buy the wildcard, so I just bought the wildcard and they’re just plain doing it to save the bucks and the only thing I’ll offer on that is usually the bucks you are saving are not very much at all. You know what, I like to save a dollar as much as the next guy does but you need to consider the risk that you are taking on for yourself and if you are really doing this to save a few hundred dollars a year which often times is what we are talking about, I’ll ask, gosh, aren’t there a lot of other ways your company can save a few hundred dollars a year that are less potentially consequential and why don’t you go do one of those instead. So, you know, that’s just an important thing to consider when you are looking at the two items in your spreadsheet and one has a lower dollar figure that the other, this is a true TCO situation where you really need to think about the total cost of ownership not just what your outlay is going to be on the corporate credit card right now.

Jason SorokoYou know, Tim, I think there is another aspect to this which falls right off of what you just said, which is if you are a growing business you anticipate having more than a few handful of fully qualified domain names within your web structure then, yes, it may cost you a little extra to get a few more single or multi-domains down the road rather than that wildcard but on the other hand, there used to be the issue of well now I’ve got to manually track all of these certificates and this just gets back to another theme of our podcast, which is certificate automation is just so important here and that’s a way to make this a moot point. If you’ve got more than a handful, all of the sudden the human brain has difficulty in dealing with remembering all of the different certificates that you are gonna have to remember about where they are and what domain names that they are actually associated with, but with modern forms of certificate automation and the way you manage these things, that problem kind of goes away.

TCTim CallanYeah. And by the way, if that’s why you are doing it, if you are getting multi-domain or wildcards simply because you want to reduce the number of renewal episodes that you have, remember that the risk associated with those renewal episodes just went up by the multiple of how many domains you are covering with that cert. So in the event that there is a problem, in the event that the cert is allowed to expire without being replaced for whatever reason, instead of losing one server, you just lost many more. And that’s the, you know, that’s a variation on the same thing that we’ve been talking about but that’s another way to think about it. If what you are doing is you are trying to reduce the number of times you have to touch a server then there are better ways to do that today. Ten years ago? Yeah, you are right. But now there are better ways to do that and it’s about automation and there are lots of automation options available out there.

Jason SorokoSo, I guess, Tim, final thought from me here is there is value. There is security and risk mitigation value in explicitly stating to the world which fully qualified domain names that you want to expose to the world, and you do that by - - you can in fact, you don’t have to have a ton of certificates for that. You can do it in one or two or three within a multi-domain certificate. That’s fantastic. It explicitly states which fully qualified domain names that are allowed. There are many ways to handle that, and I think it can even be made very, very manageable. It’s the wildcard certs that we are worried about. Why would I use them? I would use them if I were a very, very mature organization that was right on top of all my risks and my website structure was so variable daily that it’s just untenable to maintain new certificates daily. That’s the only scenario to me that makes perfect sense. I think though that because - - I’m thinking right now of something like Let’s Encrypt where you can get a wildcard certificate. This is where I think as practitioners in the space, Tim, this is where we are looking and going goodness, these things are probably being overused right now.

TCTim CallanYeah. Yeah. They certainly are over-used. Anecdotally, there’s no question because we see these anecdotes all the time. It’s hard to put a number on that because how would you measure that, but we do see examples of this really on a regular basis and, you know, I think what we’ve talked about is a good way to think about it. You want to think about your ability to maintain your overall security, your ability to be very agile if something needs to be happening with your certs very quickly and you weigh that against the consequences of their being a problem or an outage or an expiration flaw and then try to mitigate that as much as you can with automation, right? Which makes the need for multi-domain and wildcards go down. And that’s probably, like as a general umbrella statement that’s the way to think about it and that’s the best practice.

Jason SorokoThat’s it, Tim. Thank you.

TCTim CallanAlright. Thank you, listeners. Thanks, Jay. This has been Root Causes.

Stay informed with expert insights

Subscribe to Root Causes for engaging discussions on PKI, digital security, and best practices for protecting your organization's critical assets. Don’t miss an episode!