Root Causes 181: Limitation of DCV Through Web Site Changes

Hosted by

Tim Callan

Chief Compliance Officer

Jason Soroko

Fellow

Original broadcast date

August 30, 2021

This December will see a meaningful change in how CAs are allowed to conduct Domain Control Validation (DCV) using the method known as https token or file authentication or agreed up on change to web site. This method will be removed as an option for "domain spaces" including wildcards and subdomains. Join our hosts as they explain how DCV works and how the rules are changing and why. And we clarify the available options for those changing their preferred DCV methods.

Podcast Transcript

Lightly edited for flow and brevity.

Tim CallanSo, I want to talk about today is there’s a very important change coming up in the SSL authentication rules as put together by the CA/Browser Forum and it’s going to be non-trivial and, you know, sometimes when these things happen in the past, Jay, when they were big, we did an episode on them. Like, for instance, when the allowable term of SSL certificates got shortened to one year and things along those lines and I think this one is worth going over today just so that the listeners can understand how that is changing.

Jason SorokoYeah. Thanks, Tim. I like these episodes because it really keeps us up to date on what’s going on in that world.

Tim CallanOk. Yeah. So, there is a change that is coming about through the CA/Browser Forum rules, what we call the baseline requirements and this was passed by a ballot in the CA/Browser Forum in June and this change, this rule, will go into effect on December 1 and we will return to the calendar on this I think later on in the episode, but it is a change to what we call DCV. And DCV stands for domain control validation and that’s basically how you demonstrate that you control the domain. It’s all really right in the name. It’s validation of the control of the domain. So, the subscriber has to do something that proves that the subscriber, the person who is requesting the certificate is in fact the person who controls the domain name for which the certificate has been requested and that’s what we call in short hand, DCV.

Jason SorokoYeah, Tim. So, for those of you who are technical here, I’m interested to hear what Tim has to say. The way that I’ve personally done it many, many times – many times in the past – is to put, basically what’s the equivalent of a shared token into my DNS setting.

Tim CallanOk. Yeah. And that is one of the methods. There are three main methods and let’s go over those. It’s probably a good time to do that. And there’s a bunch of variants on these, but these are the three main methods that you can use to verify control of the domain.

One of them is you do what you just said. You take the shared token or you take this secret that’s been given to you by the CA that you couldn’t possibly have predicted - think of it as a random number for want of a better way to think about it - and you put that in your DNS in a certain expected format and then the CA has software that goes and looks for it and when they find that token in your DNS, they know the only way that could have happened is if the person who requested the certificate has control over DNS settings. So, that is one of the ways to establish control of their domain. Or validate if we will, control of the domain because it is domain control validation. That’s a popular one.

Another popular one that’s been around for a long time, I think it’s been around forever, is you do a similar thing but instead of putting that token in your DNS settings, you actually put it on the HTTP page for the domain in question. So, I actually get a file. I put that file on my site on that domain and then the software comes; it sees that file; it reads that file; it sees the secret; verifies that the secret is correct and says, ok, the only way this is possible is that the requester of the certificate has control over this domain and we often refer to that as HTTP or HTTPS DCV or we might call that file auth or HTTP token or something along those lines.

Jason SorokoYeah. Quickly, again for those of you who are technical, the reasoning for that option as far as a can tell is if you are hosting your website through a hoster and sometimes you might not have access to your DNS settings, that’s why you would want a file option.

Tim CallanExactly right. So, DNS - - DNS is a little more on the advanced end of the scale. I mean the very advanced end of the scale. It’s very advanced. But, there are people who are perfectly capable of owning and operating a website and authoring and uploading HTML who don’t really either have access to or feel comfortable monkeying with DNS settings and for those people, it’s another option and it’s a very popular option and, as I said, it’s a very old option that’s been around for a long time.

So, just in the interest of completeness, the third main way to do it is what we call emailed-based authentication. So, what happens in this case is the CA sends an email to one or more constructed email addresses. So, it’s things like [email protected]. Right? And there is a set of like five or six of those and you can pick one or more of those as they go out to those domains and by virtue of the fact that you are able to receive that domain - - sorry – receive that secret, because the secret is sent, again, in your email and then you get back to the CA and tell them what the secret is and if the secret matches, then what you’ve done when you do that is, once again, you’ve demonstrated control of the domain. So, those are the three main methods and they break down into variants and subcategories and stuff but we don’t need to get into all of that today.

So, what we are talking about today is a change to the second of those two. The file-based domain auth and, in particular, it is a narrowing if we will, let’s say a deprecation of a certain methods of using file-based author. Certain things that you could validate that you won’t be allowed to validate moving forward. And it’s two main things.

So, the first of those is for wildcard certs. So, in the event that I want to use to validate a wildcard domain, or validate a domain for a wildcard certificate, I no longer can use file-based DCV or HTTP-based DCV in order to that. Simply disallowed. So, if I have *.mydomain.com, I cannot use file-based DCV to do that and the reason for that is simply that there is not enough demonstration of control of all of the subdomains that that wildcard might service, that I could use that to get a wildcard cert that would act as subdomains that I shouldn’t rightfully have access to and by eliminating that option that is no longer a situation that can occur.

Jason SorokoI think that’s completely reasonable, Tim.

Tim CallanYeah.

Jason SorokoYou know, the demonstration of control is what’s at the heart of this and that is absolutely a condition that has a fallacy that needs to be deprecated. That’s a good idea.

Tim CallanYeah. And then the other one is kind of a variation on this. So, one of the things that’s allowed - - and by the way, that’s allowed by the rules today. Like, today, according to the CA/Browser Forum rules, you can validate a wildcard domain this way. So, any CA that’s doing that now is not breaking the rules, it’s just that the rules are going to change.

The second one is a variation on the same idea, which is right now according to the rules, if I use HTTP DCV on a domain name, that automatically is applicable to any subdomain as well. So, if I go get a file-based domain validation for mysite.com, then I can order a cert for shop.mysite.com without having to undergo DCV a second time and it’s the same exact concern. The concern is that there are scenarios and use cases where there are subdomains that perhaps are not in control of the same people and by giving the owner of the apex domain the ability to order certs for those subdomains also that it potentially leads to an issuance versus control mismatch. The exact same way that the wildcard scenario does.

Jason SorokoYeah. Again, Tim, I think this is all making a lot of sense. This is some clear thinking here.

Tim CallanYeah, but in this case, in the case of the wildcard, it’s just too bad. Right? You just can’t do it because it’s a wildcard. In this case, there is another option, of course, which is you can just validate every subdomain you want to use. So, you can still go get a multi-domain certificate for a whole bunch of subdomains. You just gotta put the file on every one of them and, you know, if you put them all on the order, you’ll get the same secret for all of them, you can, you know, usually, there is a pretty automatic way to get that out there on all of them. So, that’s isn’t necessarily any particular hardship. Depending on your level of technical savvy or your level of automation, it may not be a problem at all and so, in that scenario, continuing to use file-based DCV might be perfectly fine but you have to do it in a slightly different way and you have to make sure that you do it correctly.

Jason SorokoThat’s great, Tim. Now let me ask you - - in terms of the email version, the email validation, have there been any concerns expressed at the table about email account compromise? Because that’s always something, you know, that’s not new. That’s a problem that’s been known since the beginning. It’s the chance that we take, but has there been any talk about potential changes to that one?

Tim CallanThat is not really on the list right now. I think to some degree it is the chances that we take. One of the grim realities of our modern world is that email is not terribly secure, and it is considerably less secure than most of us seem to think that it is. You and I are maybe exceptions to that rule, but, you know, most people, even computer savvy people, tend to think that email is more secure than it really is. So, that is a reality. That is something that I could imagine being addressed in the future. It is an option that’s still available today and it’s not something that’s in the immediate future.

Jason SorokoOk. Thanks, Tim. Everything you’ve said here so far makes sense in terms of what’s being changed and deprecated. These are completely rational ideas.

Tim CallanSo, it’s a pretty simple story. We are almost at the end of it. So, these new rules, as I’ve described, those are the rules not any other ones, they go into effect as of December 1, 2021. So, as of December 1, the CA may not issue certs that do those old things. Right? They gotta do it the way we just described on this episode. And, we at Sectigo, as is our normal policy, will be leading that by a little of time just to make sure that there’s no chance of an overlap or a miss or somebody trying to order a cert and they can’t get it. So, for us, we are gonna enforce November 15 as the first day where we follow the new rules and we disallow the old deprecated option. So, on November 14, you can use filed-based DCV for your wildcard cert, but on November 15, you can’t from us.

Jason SorokoYeah, and I’m sure that this is gonna have implications especially for different kinds protocols, agents. I’m thinking of ACME as an example. So, therefore, the ACME protocol will have to enable these rule sets as well; otherwise, you will be out of compliance. So, there’ll be some work to do in order to make everything comply.

Tim CallanYeah, and so, that’s part of why were doing this now is giving everybody plenty of notice. This should be pretty simple. It should be pretty straightforward. People have a lot of time to make these changes, but, you know, if this does affect your roadmap in any way, if this is something you need to do, get it on the roadmap. Get it done. And just as we’re not gonna wait for the last minute in case there’s a problem, don’t you wait for the last minute either. If your roadmap has you fixing whatever you need to fix on November 14 or the Friday before that, whatever that is – November 12 – maybe give yourself a little more time than that and, you know, as long as everybody pays attention and does this, this really shouldn’t cause you any kind of hiccup as a subscriber.

Jason SorokoYeah, and if anybody listening to this has any questions, because there definitely are some implications to this if you’re running websites, reach out to us so we can help you.

Tim CallanYeah. Absolutely.

And let me just leave you with one last thing. If you are a stickler for details and you want to learn more, the methods as described in the baseline requirements that are being changed are what we call DCV Method 18 and DCV Method 19 and these are detailed in the most current version of the baseline requirements in Section 3.2.2.4.18 and no surprise, 3.2.2.4.19 and if you just search CABF baseline requirements, you’ll find that document and you can go through and actually read for yourself. So, those are the sections that are being updated and that’s where we are.

Jason SorokoThank you so much, Tim.

Tim CallanThank you, Jay. Thank you, Listeners. 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!