Root Causes 523: Will Your Configuration Block MPIC DCV?

Hosted by

Tim Callan

Chief Compliance Officer

Jason Soroko

Fellow

Original broadcast date

September 3, 2025

MPIC (Multi-perspective Issuance Corroboration) is soon to move into enforcement phase. In this episode we describe three configuration decisions that can force Domain Control Validation (DCV) to fail and tell you what to do about them before you have a problem.

Podcast Transcript

Tim CallanJason, MPIC, multi-perspective issuance corroboration, is moving into a new phase, which is the enforcement phase.

Jason SorokoWe're finally there.

Tim CallanYes.

Jason SorokoWe've been talking with this topic for so long.

Tim CallanAnd so, as a reminder to the listeners, multi-corroboration, multi-perspective issuance corroboration, the idea is in order to beat a Border Gateway Protocol attack that CAs, when they do DCV, have to actually look at the domain to do DCV from multiple places around the world, and the number of places will go up over time. Right now it's at two.

Jason SorokoTwo. which is the bare minimum, other than just the usual one. It makes it difficult for the bad guy to be able to sort of toxify or to change or modify the internet addressing.

Tim CallanThe scope of the BGP has to get so much bigger. If I can do something locally, if I happen to know where the CA is going to be checking from, I could maybe attack - it would attack locally. But if the CA is checking from two different continents then just the scale of the attack is so much greater. And it starts with two, but it's going to grow into more and more than that, which makes it even, even harder to do this kind of attack. And so this is good. We like this. This is more secure. We are moving into this enforcement phase. So since March 15 of this year, we've been in a monitoring phase where the CAs just have to, they have to do the checks, but they don't act on them. And this is to give CAs time to get all of their technology in place, make sure it works, shake out the bugs, things along these lines. Now, September 15, this is the first date of enforcement and one of the interesting things that has come along as a consequence of this is we've seen during the monitoring phase that there are, let's call it server configurations, for want of a better word. There are decisions you may make technologically as the subscriber operating the servers, which, until now, had no negative consequence, but now at least threaten to prevent DCV.

Jason SorokoWow. So we've learned something during this monitoring phase.

Tim CallanThat's what it's for. I think we will uncover more of these. But I basically, I have a list of three of these right now that we know do occur in the wild. Fortunately, they're rare, but unfortunately, they do exist. Like they do come up and again, if you're doing this, this could cause your DCV to fail, and these are configuration changes that subscribers can make so this doesn't happen anymore. So we just thought we'd say what they were, and maybe some of the listeners can go check their own systems and see if this has occurred or not.

Jason SorokoI think this is important. Let's hear it, Tim.

Tim CallanSo the first one is geofencing, or otherwise geographically restricting the IP addresses that can access your service. So if you say, look, I'm only going to be available in this country, and suddenly DCV must, by definition, come from out of the country, you are guaranteeing failure.

Jason SorokoSo some people are geofencing. I can imagine some very small number of regions being geofenced off, but it's are we finding it's common to have.

Tim CallanAll of these are rare, but all of these are recurring on their own, so that means someone somewhere is going to have a bad day and not know why. And so we're trying to communicate. So we've got assets and blog posts and things like on our site to try to communicate this. I just like to do it here too, because it's another channel for us to get it across.
So geofencing or geographically restricting is problem number one. Problem number two is very similar. It's using an allow list. So I've got an allow list of places that can come in and check for this, and it includes the IP address that I'm used to from the CA and now all of a sudden, by definition, it has to come from different places.
So, it's a similar problem where you set your servers up in a way where, literally, we can't come in and look from different places.
So that's not gonna work. Like up until now, it's probably perfectly fine. But just now it won't be.

Jason SorokoSo, Tim, just on that note, you said something very important. The onus is on the subscriber who is actually triggering the DCV.

Tim CallanThis is very important. All three of these are things that we cannot fix on our side.
These are things that, the way the technology works, only the subscriber can fix. If they were things that we could solve, we just would have. But by definition, the way MPIC has to work we must do these things and if the subscriber sets up their servers that way, we will not be able to proceed.

Jason SorokoBefore you get on to the other ones, I just want to go off what you just said, because we on this podcast had said MPIC was an inside baseball to the CAs, subscribers will never have to think about this, and now they're having to think about this.

Tim CallanAnd I think that's a good point, Jay. I hadn't thought about that, but you're absolutely right. In general, we need to be cautious whenever we make the world of the WebPKI and the world of PKI in general, is a big, complex place, and when you come up with these general statements like this, you got to be cautious. Because it could be that there are exceptions. Perfect example, I remember sitting right here and say, ah, you'll never have to worry about it. I'm just telling you because it's interesting. And here we are. Now we've learned that there's a small, fortunately small set, but a non-zero set of subscribers who do need to worry about it and are going to have to do something.

Jason SorokoPerfect, Tim.

Tim CallanSo number three - thank you for observing that.
Number three is some people will configure the shared secret file to delete once it is checked, which you understand from a cleanup perspective, seems like a good policy. The problem is it needs to be checked more than once.

Jason SorokoOf course. From multiple places.

Tim CallanFrom multiple places. So we've seen people who the first check succeeds because and then the file gets deleted and the next check fails because there's no file anymore. Which again, in a world of traditional DCV, seems like a perfectly good, possibly even a best practice. However, in an MPIC world, you're guaranteeing failure.
So what we need there is you can still do the cleanup. Cleanup is great. But why don't you do something like a cron job once it's checked, and don't clean it up for a week. Still get cleaned up. File can sit there for a week. It doesn't matter. You don't have old files accumulating, but you also don't break MPIC or have something where it cleans up the file once the new certificate is issued, if you can figure that out. So something like that is, uh, there are a number of ways you can do it where you still get the cleanup, but this instant delete after checking - not gonna work.

Jason SorokoSo, Tim, I hesitate to pause you, but now I'm thinking, if I'm vanilla ACME subscriber, haven't done any kind of special configurations other than set up my cron job, things like this, there's probably not much for me to do here.

Tim CallanYou're absolutely fine. Among other things, there is ACME DCV, which is one of the methods. Which we love, and you won't have any of these problems.

Jason SorokoThat's exactly what I was thinking. So hopefully that is the majority of you who are listening to this, but for some of you who have done special configurations, we have some documentation to help you out.

Tim CallanAbsolutely. So again, you can find this on the Sectigo website. It's the three things - it's don't automatically delete the file as soon as it's used. Give us a chance to find it again. Don't geographically restrict or geofence who can check you. And don't use allow lists those. Those are the three things.
Now I'm going to also say these are early days. I expect that as enforcement comes into play, more of these things will come up that we don't know yet. We will augment our online resources as that happens. If it's enough information and it's interesting enough, you and I may come back with an update with more things. This is what we know today. I figure there will be more.

Jason SorokoSo if you're having some sort of an unknown error within your DCV process, it could be related to this, so get a hold of us.

Tim CallanI would at least, I would at least try these three things. One of the things we find in general when these kind of sweeping changes are made is lots and lots and lots of subscribers don't know 100% of what's going on in their own environments. I remember this with our 2021 root expiration, where we communicated with all our enterprise accounts and said, this root is expiring. And what we heard almost universally was, ah, we don't use it doesn't matter. And then once the expiration occurred, all kinds of people, it turned out, were pinning to that root and didn't know it. So the didn't know it problem is a thing where there's somewhere in your world or your environment, someone 12 years ago who hasn't worked here in the last 11 years who didn't document it, made some decision, and it's run fine, and no one's aware. And suddenly something starts working, and we don't know why. And this is, in general, the trouble with spaghetti code, and is definitely the trouble with this kind of thing. So those are things to go look for, and certainly, if you uncover something else, please contact us, because we'll put it in the FAQ, and maybe you'll help another subscriber as well.

Jason SorokoPerfect, Tim. Thank you.

Tim CallanAll right. Thanks, Jay.

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!