Root Causes 211: Does CLM Make Wildcard and MDC Irrelevant?

Hosted by

Tim Callan

Chief Compliance Officer

Jason Soroko

Fellow

Original broadcast date

March 14, 2022

Wildcard and multi-domain certificates have traditionally made administration easier for IT departments. In this episode we weigh the degree to which Certificate Lifecycle Management (CLM) renders these benefits obsolete and if these certificate types continue to be worth the increased risk they carry.

Podcast Transcript

Lightly edited for flow and brevity.

Tim CallanWe are going to have a discussion today and we don't actually know where the other guy stands on it and I'm not sure in my case, even where I stand on it, but we thought we'd explore a topic. This was mentioned by a colleague of mine not that long ago and I thought it was interesting and thought provoking. Does CLM - Certificate Lifecycle Management - make multidomain and wildcard certificates irrelevant?

Jason SorokoThat's a great question. And I think, gut feel, I think there's definitely some merit to that idea.

Tim CallanThere's something to that idea for sure.

Jason SorokoI'll go further, we have touched on this topic in previous podcasts, because we've talked about wildcard certificates and we've talked about the risks and I think it's worth going through that again, Tim, and, I'll kick at the can here, and you can help me out. I think the idea is, for those of you who administrate web servers, this, this topic is for you and for those of you who have a lot of subdomains within your web properties, this is absolutely a topic for you because what you will avoid with using a wildcard certificate in the subdomain scenario is having to issue a different certificate per subdomain. Now you have other choices. You can issue a discrete list of those subdomains into a multidomain certificate, but a wildcard just makes it easy because then you don't have to restrict that list. You don't have to know ahead of time - -

Tim CallanA wildcard is future proofed. When I get the certificate, I have no idea I'm gonna want to have a test environment27.mydomain.com. Later on, I realized I need a test environment 27 and it's ok, because I'm already covered.

Jason SorokoExactly right. So therefore, this is a, hey, I don't want to have to think about this too much timesaver. The wildcard gives you that. That's why it was created. There really is no other reasoning for it. However, if your web property is compromised, just like you creating a new subdomain, you are now at the mercy of the bad guy creating a subdomain on your behalf maliciously and that subdomain, by definition from that wildcard certificate will be covered?

Tim CallanIt's covered by a legitimate certificate that you got that's assigned to you. Absolutely. That's the big worry there, for sure.

Jason SorokoSo therefore, how good is your ability to police your web environment? In other words, you might say to me, I don't got to worry about wildcard and I don't got to worry about that scenario, Jay, because I would know that that subdomain is created. How many of you would raise your hands and guarantee to me? Because a lot of these phishing attacks that would utilize a subdomain within a compromised, web server endpoint - goodness, some of these phishing attacks happen over a matter of hours and are you fast enough to catch it?

Tim CallanI've seen statistics that say that your average phishing site lasts less than a day. So, if you're not sitting there staring at your screen right now you’ve probably missed the entire event.

Jason SorokoI can see people saying, look, for whatever reason, I don't want to have individual certificates per subdomain. Then you've got the multidomain for a discrete list. Unfortunately, if that list changes, you need to issue another certificate. And therefore, once again, we come down to well, wildcard is just better for that. So, our colleague’s argument in that certificate lifecycle management, modern certificate lifecycle management, is, helps to do away with that, I would have to argue that if your systems are well automated enough, calling up that extra certificate is really not a challenge or a problem, or even most importantly to you and I, Tim, the risk of outage because you're not keeping track of that cert is - - that goes down to a very low risk when you're doing proper certificate lifecycle management, and you're automating everything correctly. If we look at the full spectrum of why is it, why was it, a pain in the neck to have individual certificates per subdomain, it was simply because you had a job to do. There was a cost associated to provisioning, issuing, provisioning and installing that certificate where it needed to go and making your web server configuration changes that were necessary. There was a certain amount of time that had to be spent for each one and you might think to yourself, well, that's a whole lot of certificates I now have to keep track of for the renewal process. Well, all of that kind of goes away with modern certificate lifecycle management, Tim, because why am I even calling a discrete list within a multidomain certificate? Why am I using that risky list, unlimited list, which is essentially what a wildcard gets you? Perhaps why not just use individual certificates per subdomain, or as you need two or three call some multidomains depending on what you're doing. Frankly, when the whole thing is automated properly, that whole decision-making process back in the days when everything was manual kind of goes away. I'm tending to agree with Abul and his blog.

Tim CallanSome of the other reasons that somebody might elect for a wildcard or a multidomain would be that they feel that they're getting the coverage they want for a better overall price but that's a pricing and packaging issue. That certainly is solvable other ways. If the SSL provider is not prepared to make 70 individual certificates available for you for the same price as the 70 domain multidomain cert, then you can work that out with them.

Jason SorokoThat's exactly right. We are talking about if you're making the argument that you're switching or creating new subdomains so quickly that you need a wildcard then chances are you will be able to have a very good negotiation stance with a CA. I don't think there is any question about that.

Tim CallanThat addresses the wildcard scenario and as we've talked about, the wildcard scenario has that obvious risk factor that people create things under your nose and you don't know it, and one of your lines of defense of that would be certificates and that's just not there.

What about the pure multidomain scenario? So, I've got a multidomain certificate. I'm creating multidomain certificates and if I have good CLM in place, conceivably I could just have a bunch of single domain focused certificates available instead. How do you feel about that?

Jason SorokoIf it's a static list - if your list of subdomains is static, and you explicitly name them within a multidomain certificate, I don't see any problem with that at all. Really, this podcast, and the topic we're talking about is the non-static environments where you have a lot of subdomains or if not subdomains, a lot of other properties that could come under a multidomain. If that list is static, that multidomain cert makes sense. However, we've also talked about that on this podcast where keep that list short, and I'm not talking one or two. I'm sure it can be a handful. Maybe somebody out there smarter than me, maybe you, Tim, can tell me where the ideal length is, and not to go over. But I would say a mistake you can make with multidomain certificates is to perhaps pre-plan too much. If those properties or subdomains or other domains are not created yet or used yet, I would say don't stick them onto a multidomain certificate in anticipation. And it's for the same reason we cited previously, which is you want to assume that you won't be caught with a compromised situation where something is being created unbeknownst to you and being covered by that certificate.

Tim CallanOne of the multidomain use cases is I have a cluster that's serving up content from different domains or subdomains altogether and so I just want to have a cert that will account for all of those. In that scenario, I agree with you. There's a good argument for that. It has to do with the other ways that you're architecting your services, but you may still have opportunities to minimize the number of subdomains we're talking about. Maybe you don't have to have 40, maybe you could have 10. And maybe the automated certificate management aspect of the business enables that sort of thing and allows you to keep things more focused and cleaner, and generally that also equates to risk reduction under those circumstances.

Jason SorokoIf you think about it, I've seen scenarios where some companies have small, underused subdomains that are meant for experimental purposes or for services that are internal use where they're not scrutinized quite as much as, say, your main web property. If you have a multidomain certificate that covers both your main subdomain or your main domain, and also covers these lesser scrutinized subdomains, or other domains, which is a possibility in a multidomain certificate, it's not, it's not just multi-subdomain, it's multidomain. Therefore, if you have to somehow revoke that certificate because it's been compromised, or there's a problem, it's, there is a big argument for this is why you want to have individual certificates per property.

Therefore, that, to me, is if you're gonna do a multidomain certificate, keep in mind that that list should be tight. That's why I argue it should be a short list of sites that you're totally comfortable with if one site gets compromised. If the certificate somehow is compromised, the private key is compromised, you’re ok with very quickly reissuing for those properties in total. If you've got a dozen, two dozen or more properties within that one multidomain certificate, you've got a lot of work on your hands.

Tim CallanThat's a big one. I mean, you think about a private key compromise as a perfect example because then that cert has to go. That cert has to go right now. And when that happens, everything is going to stop working until you get it replaced. So, you're just looking about what's your total exposure there. If I've jammed every subdomain I can think of or every domain I can think of all into a single cert, then all that stuff goes down all together all at once. So, that’s one reason to cut them up into smaller pieces.

Jason SorokoYou got it, Tim. That's the big argument for certificate lifecycle management, that ability to do - I've used that word before - discrete web domains being used per certificate, one domain per cert, it reduces the amount of work you have to do when there is a compromise.

Tim CallanI think I agree with that. So, it seems like we're falling, we're both falling on the camp to say that, it's not that I think either of us is expecting wildcards or multidomain certs to go away, and certainly there are cases where multidomain seems to make a lot of sense, but in general, robust CLM in place working correctly in the enterprise ought to enable a very significant reduction in the reliance on especially wildcards but also multidomain certs. Do you agree with that?

Jason SorokoI think this comes down to this - a lot of certificates over the years have been ordered the way they were because it was simply handy. People were not looking at what happens if bad things happen. If bad things happen, wildcards are not your friend, and multidomain certificates that are overly used are not your friend. I completely understand the argument of oh, my goodness, this is difficult to manage, you no longer have that argument with certificate lifecycle management.

Tim CallanThen you've brushed upon the other thing that's going to, of course, be a sticking factor, which is this is the way we've always done it. You have people who are comfortable with a certain process and used to that, and maybe it's even codified somewhere in some kind of set of rules they're supposed to follow. That's just what they do.

Jason SorokoThat's why we're bringing it up on this podcast. It's food for thought for those of you who are doing certificate procurement, and you're trying to plan out your certificate purchasing and whatever it is, however it is you're going to be setting things up. I think that nobody has done a great job yet of connecting the dots of certificate lifecycle management should fundamentally change behaviors that are so entrenched, and I think in this case, that this is a really good example.

It's food for thought for those of you who are doing certificate procurement, and you're trying to plan out your certificate purchasing and whatever it is, however it is you're going to be setting things up. I think that nobody has done a great job yet of connecting the dots of certificate lifecycle management should fundamentally change behaviors that are so entrenched, and I think in this case, that this is a really good example.

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!