Podcast
Root Causes 385: Failed Revocation and Wildcard Certificates
Hosted by
Jason Soroko
Fellow
Original broadcast date
May 10, 2024
We discuss misuse of wildcard certificates, failure to revoke on time, and how these two failures magnify each other.
Podcast transcript
Lightly edited for flow and brevity.
TCTim CallanOkay, so we have over the last two months, had a lot of conversations about this constellation off interesting events that's going on right now, that in the grand scheme of things we refer to as the Bugzilla bloodbath, and also real specifically, in this phenomenon, this epidemic right now that's sweeping the world of public CAs about incapability or unwillingness to do revocations on time.
And I wanted to quote, a specific line from a specific CA’s Bugzilla incident in which they are failing to get their revocation done on time, and I'm going to just read this passage, this pair of sentences from the CA's bugs. Again, this is a bug where the point of the bug is they're not getting the revocation done on time. So let me read this quote. “The remaining two wildcard certificates involve multiple hosts. Most hosts have either completed the replacement or switched to certificates from other CAs. However, some hosts still require configuration changes to be made by vendors. We will allow an additional two week extension.”
So basically, what the CA is saying is that they have some certificates that they failed to revoke on time and their rationale for this is that these are wildcard certificates and there are a bunch of different people using the wildcard and not all of those different people have done their work to swap out the certs. So that even though some of them have, they're still not revoking the cert because some of them have not. So before I go further, Jason, do you have any comments on that?
And I wanted to quote, a specific line from a specific CA’s Bugzilla incident in which they are failing to get their revocation done on time, and I'm going to just read this passage, this pair of sentences from the CA's bugs. Again, this is a bug where the point of the bug is they're not getting the revocation done on time. So let me read this quote. “The remaining two wildcard certificates involve multiple hosts. Most hosts have either completed the replacement or switched to certificates from other CAs. However, some hosts still require configuration changes to be made by vendors. We will allow an additional two week extension.”
So basically, what the CA is saying is that they have some certificates that they failed to revoke on time and their rationale for this is that these are wildcard certificates and there are a bunch of different people using the wildcard and not all of those different people have done their work to swap out the certs. So that even though some of them have, they're still not revoking the cert because some of them have not. So before I go further, Jason, do you have any comments on that?
TCTim CallanYeah.
TCTim CallanRight.
TCTim CallanYeah.
TCTim CallanOh, yeah. This whole thing is just so fragile. First of all, it's the opposite of agility here, right? This is ossified. I mean, you can't, if you can't even revoke your own certificate because you feel you're going to break somebody that you don't want to break because they're sitting on your wildcard and you can't rely on that somebody to do the things they need to do, all I can say is yikes. Like, what would have happened if one of these individual hosts was trying to get the certificate revoked? Are they going to be disallowed from revoking their own certificate?
TCTim CallanIsn't that incredibly scary? And, I mean, this is obviously gross misuse of a wildcard. You can't. Obviously, technically they can, but it's a crazy idea to use a wildcard in this way where you're taking your wildcard cert and you're just plunking it down on a set of these properties, these servers that you have no visibility or control on whatsoever. Like it's just, like this is spread across these different hosts and they're not all - - they don't seem to know each other. Right? It’s just - - what a terrible practice and how completely - - first of all, you're putting all of your eggs in one basket. You are completely anti-agile. Right? You're just incapable. There's no agility and flexibility whatsoever and I'm hard pressed to imagine that that kind of architecture is necessary.
TCTim CallanIf these are different hosts and they're running they're different properties then give them different certs.
TCTim CallanThis is what’s certs are for. Yeah.
TCTim CallanYeah.
TCTim CallanRight. Yeah.
TCTim CallanOh, I agree. I agree. Like this is just so broken in so many ways. And what if, what if it were a 24 hour revocation event? What if it were an inflexible sorry, ain't given you no extension 24 hour revocation event? What if it were a DCV error? What if it were a private key compromise? Then are these various, random, seemingly large number of who knows who they are hosts just going to just break and have to deal with it? I think the answer is yes. That's what's going to happen.
TCTim CallanRight. Yeah. And so like, what about, if I'm one of these hosts, I should not want to be in this relationship either where I'm depending on some certificate that I have no visibility or control over to keep me up and running and somewhere along the line, someone else might make bad decisions and the consequence of that person's bad decisions will be that my services go down.
TCTim CallanSure. Bad Corp.
TCTim CallanOh, we had - - So we told an anecdote on this podcast. This was probably four years ago at this point. I can't even tell you what the episode was but where we had had a revocation and it was a single - - it was one off. It was something like a private key compromise and we went in and we revoked the cert and next day, this angry customer is putting something on his Twitter saying my cert just got revoked. Now I have 300 businesses that are down. Thanks Sectigo! And my first response to it was so you had 300 disparate separate businesses, who had nothing to do with each other, who didn't know each other all sitting on that same wildcard cert? Really? Like I'm sorry. Sectigo is not the bad party here. It is that hoster.
TCTim CallanNo. This is the direction. Right? So, yeah. And it's just interesting. Like, it's this constellation of problems, right? If we look at some of the things that make, you know, the web PKI and public SSL certs less than their potential, overuse of wildcards is one, this failure to revoke problem that’s going on right now is another, and just seeing those kind of intersect and collide in this way, was really interesting.
TCTim CallanAnd kind of showed and, and then they exacerbated each other, right? The overuse of wildcard problem is aggravating the inability to revoke problem. And so it's kind of this negative, uh, what’s the word I'm looking for? It's kind of this anti-synergy that's occurring.
TCTim CallanYeah, absolutely. And this overuse of wildcards thing has been going on a long time and I fear that we're going to be discussing this one for a long time.
TCTim CallanYeah, you don't have any certificate agility. I’m sorry. Total certificate lack of agility.
TCTim CallanAnyway, that was it. It was just, that was such a jaw dropper, I thought we had to talk about it today.
TCTim CallanThank you, Jason. This has been Root Causes.