Root Causes 445: Seven Reasons to Shorten Certificate Lifespans

Hosted by

Tim Callan

Chief Compliance Officer

Jason Soroko

Fellow

Original broadcast date

December 9, 2024

We take a deep dive into the seven reasons shorter certificate lifespans are better.

Podcast Transcript

Lightly edited for flow and brevity.

Tim CallanSo you and I recently published a podcast episode where discussed about updates and changes to Apple's stepdown process for certificate term, going from what today is 398 days down to what will now be 47 days according to the new proposal. During that episode, you suggested that it would be great to peel off a separate episode and simply talk about the reasons that shorter certificate lifespans are better, and I loved the idea, and so that's what we're doing today. I've got a list of I think probably five things. I don't know how that compares to your list, but let's go through them. Which one do you want to pick first?

Jason SorokoTim, I like to always talk about the hardest of hardcore – cybersecurity. You can't talk about this topic without first mentioning private key compromise. If you think about this, Tim, and this is true whether it's publicly trusted certificates or private. You absolutely want to have shorter certificate lifespans. You remember, Tim, back in the day when we had five and ten year certificates, pre-CA/Browser forum days.

In the private world, you can go to Black Hat and DEFCON and look at some people who've done their private certificate authority setups with, 10, 15, 20-year certificates that are signing their issuing CAs and the bad guy basically saying, hey, I've popped your box, and guess what? I now have your private key. I'm able to do man the middle attacks against all of what you thought were encrypted in transit communications and Tim, if you think about private key compromise, you would want as short certificate lifespans as possible. In the private world today, Tim, in some use cases, we're thinking, we're looking at keys, certificates after key generation that are really only meant to be lasting a period of maybe up to two hours in some DevOps use cases. And there's good reasons for that. I just don't think we can not talk about private key compromise as a reason.

Tim CallanAbsolutely, and part of you see, the importance of private key compromise to the rules makers in the web PKI, in that private key compromise is one of the 24-hour revocation reasons, as opposed to a 120-hour revocation reason. So that shows you the importance of it.

The other thing is that there are CA/Browser forum rules that prevent CAs from issuing to known private keys. There are CA/Browser forum rules that state that as soon as we become aware of a private key we have to view that as compromised. Like even as the CA, I can't know your key, and if I know your private key, I have to call it a compromised cert, and I have to revoke it, even though I'm not going to abuse that. And so when you look at all of that, there's just incredible focus on the importance of maintaining your private keys and rightly so. As there should be.

Jason SorokoSo that's it. That's number one. And how about you start off with the number two.

Tim CallanSo number two, I'm gonna riff on your number one. Which is, private key compromise, we want that compromise to exist for as little time as we possibly can. More general certificate misissuance. We have the exact same situation. So certificates could be misissued a bunch of different ways. They could have wrong information in them. They could have wrong morphology. They could have other problems that render them either less secure or less compatible than we want in the web PKI, and in the event that this misissuance is discovered, obviously the cert will be revoked, or should be revoked, let's say. But in the event that the certificate is not discovered, it is still important that those get cycled out as soon as they possibly can. So let's throw that into number two, misissuance pretty much in any form.

Jason SorokoI'll even throw in there, Tim, because it's one of my favorites, but DCV. If one of the Certificate Authorities has problems with their domain control validation, there's a bug in how it occurs, there is computer code which is always fallible.

You know all about the revocation period for that. It's important one. So it's not just, hey, there's a slightly misissued certificate with a United States state that has a capital letter, not capital letter, and therefore it's considered misissuance. Those are sometimes some small things, but there are some major reasons why misissuance happens, and might be inevitable for any CA. I would say that is a reason why you want a shorter certificate lifespan. You don't want those certificates lasting a long time in the future.

Tim CallanAgain, the importance of DCV is illustrated by the fact that DCV errors are another example of a 24 hour revocation event, because they are deemed to be particularly important. So let's riff off that.

So another one, which I think is a huge one, is alignment of certificate ownership and domain control.

So I just talked about this in the episode you and I referenced earlier but let's go through the math on this again, because I think it's worth discussing. Today, the maximum TLS certificate validity period is 398 days. Today, the maximum domain control, DCV reuse period is also 398 days. 13 months + 13 months. So you in theory, could go for 26 months without having to re-DCV a domain. If I DCV on day zero and then on day 397 I order a new cert, and that's a 398 day cert - - So after 13 months, I order a new cert, and I order another cert that's also for 13 months, I could have 26 months later, have a domain that had not had control verified for more than two years. And that's an awful long time.

Tim CallanTim, this is something where I'm going to put a slight pause in this podcast right now, just and make a reminder of something you and I said in the past, which is, once you start thinking about it like this, in terms of shorter certificate lifespans, there are some aspects to this where today's world right now - not the way it was before CA/Browser forum, but the world right now - with 398 day certificates, one year certs, it just seems like an enormity of time to have certificates out there and in DCV periods that last, as long as what you just quoted. It's just crazy to think about how long our certificate lifespans are right now. It's not how short they are, it's how incredibly long they still are at this moment.

Tim CallanAbsolutely. Think about not that long ago, we had three years, certs and it was even crazier. I guess that probably goes into the next one, which is crypto agility. So the idea that we can change our requirements around certificates, our hard requirements, our morphological requirements, and our encryption requirements, and things along those lines, and a requirement is changed, and we've deemed that there's a new certificate that's a new way of doing things that is better that we still sit around with the old stuff we don't want anymore, considered to be perfectly valid and not misissued, and not something where you're going to force an unwilling revocation, that is problematic. Like we want the time between when we realize how to do our cryptography better, and when we actually do our cryptography better to be as short as it possibly can be, and that very much is gated by certificate term.

Jason SorokoTim, I gotta tell you, this is, this is really important. We have had cryptographic algorithm, cryptographic primitive deprecations. SHA-1. I think you're the one who said it very recently during the podcast that happened while we had three-year certificate lifespans.

I want to remind everybody - Tim, it wasn't even you and I who said it. It was people like Bas Westerbaan from Cloudflare. We've had Bruno Couillard say this, and we've had Dr. Dustin Moody say this on this podcast, but we are going to enter a world of more richness in our cryptographic algorithms in the post-quantum cryptography era, and the chance of deprecation is that much higher because we don't know which ones are going to have a long, long life, shelf life, just because of the math. So therefore, cryptographic algorithm deprecation and the need for cryptographic agility only goes up exponentially from here.

Tim CallanNever again is an IT professional going to live their entire career using the same basic cryptographic strategy. It will never happen again in human history. So we've got to be ready for this new era. General crypto agility absolutely is on the list. And then more specifically, is migration to PQC.

So this has been specifically alluded to, at least by the Chrome program as one of the motivators behind shortening certificate lifespans, which is that they recognize, just as the SHA-1 deprecation took too long, they do not want the migration to ML-KEM and ML-DSA, when the world is ready for that, to be longer than it needs to be. And the shorter our certificates, the faster that migration will occur.

Jason SorokoYou got it, Tim. I can tell you - this is a major one. So I would say that's number four on the list, Tim. I think that number one, two and three - so private key compromise, misissuance, organization, ownership changes over domains, those are what I would consider certificate agility topics. Number four, cryptographic agility is an entire subject unto itself. I have a number five.

OCSP. One of the revocation technologies available to us for certificates that last 398, days and beyond, it has a privacy problem, Tim.

Root causes Episode 272, we go into extreme depth onto the privacy problems of OCSP, and that is the very reason for the establishment of 10- day certificates, Tim.

Tim CallanRevocation. Existing revocation checking mechanisms are less than perfect. There's not just an OCSP privacy problem, there's also a basic problem with OCSP. It has been described as a seatbelt that breaks when you get in a car accident. And I think we did an episode where we went into the trouble in that regard with OCSP, but OCSP is fundamentally defeatable, and CRL is heavy, and it slows things down. And so they're both imperfect, and when certificates get short enough in term, you feel less important. You feel that revocation and checking is less important, to the point where the CA/Browser forum and the major root programs have all agreed that for certs that are not more than 10 days in term, you don't need revocation checking at all. That the natural lifespan of the cert will solve the problem for you.

Jason SorokoTim, if I run down the list now, like of the five that we've stated so far.

I think that private key compromise is probably intuitive, although most people just don't think about it. Number two, misissuance – CA misissuance - I think that it's intuitive, but most people it's not in the front of their mind. It's on the front of our mind, because we live in a CA, and I think that as you get to number three, the organization ownership changes, most of you listening to this podcast work for organizations that own a domain forever and never think about that. But if you're one of the browser root store programs, or if you're a CA, you think about this all the time, but the actual, the subscribers to certificates probably don't think about it very much. And until we started to get into post-quantum, most people have forgotten about the SHA-1 deprecation.

And I think even though you and I issued a podcast, our Root Causes Podcast 272, on OCSP privacy problem, most people outside of the hardcore CA - -

Tim CallanThat’s a very inside the industry kind of thing for sure.

Jason SorokoI guess what I'm trying to say, Tim, is out of the five that we've just listed, probably only one or one-and-a-half of these are really intuitively known by certificate subscribers.

Tim CallanI think you're right. I think there are at least two more that we haven't mentioned. I'm aware of two more. So I'm going to save the last one for you, because I'm sure you, you, you're going to care about it. But the next one, that is kind of Tim's hobby horse, is shorter certificate lifespans mitigate the problem with CAs failing to do revocations.

So there has been a big problem in the web PKI that we've really seen illustrated this year, where CAs just don't do the revocations that they're supposed to do, and they don't do it because they don't want to inconvenience their subscribers. That's really the reason. And that played a big role in the distrust of Entrust and in general, has been a huge problem in the industry. We've covered this a lot in our Bugzilla Bloodbath series. We've talked about revocation real specifically. This is a giant problem that isn't healing itself.

Now, there is a proposal from Mozilla, which we also recently discussed, that I think would go in a long way towards solving that problem. However, shorter certificates do, too. So earlier this year in the Bugzilla blood bath, when we did our revocation by the numbers, episode, we talked about certs that were still unrevoked 60, 80 days after the precipitating incident.

Well, if the maximum term of a certificate was 47 days, then you can't have any certificates that go unrevoked for more than 47 days. And the average age of those certificates is not going to be over 23 days. And so fundamentally, it just really mitigates that particular problem. Now, as you know, it's a problem that I think should not exist, but also it's a problem that does exist, and we have to face reality on that. And shorter certificate lifespans just go a long way in solving that problem.

Jason SorokoI'm going to call this number six, the flip side to number two, because CAs can misissue, but that's inevitable, and you know it happens. It's how you deal with it. If you have shorter certificate lifespans, the how you deal with it becomes a lot more simple. So thank you for that.

Tim CallanAnd, then the last one, of course - And this is one I know you're gonna love, Jay - is encourages use of automation. And this has been explicit in the discussion of both Apple and Chrome as they've talked about driving down certificate lifespan is acknowledgement of the fact that there's a certain chicken/egg problem. That people won't use automation - at least some subset of IT departments won't use automation until they have no choice. And as certificate lifespans get shorter, somewhere along the line, we cross over a line into this world where they do have no choice, and they recognize that they have no choice, and under those circumstances, you get better results. And so that is very explicitly part of the motivation in the browsers for driving for shorter certificate lifespans.

Jason SorokoThank you for that, Tim. It's funny how number six, CAs failing to do revocation, we have literally called that Tim's hobby horse. You know what? If Jason has a hobby horse, it is number seven. What you just said. Encouraging use of automation. So, Tim, when I thought of, let's do this podcast together, I wanted to have this very, very frank fireside chat at the end of the podcast. And here it is.

I want to I want to have a heart to heart beverage in the lunchroom with every single Linux administrator out there who manually tracks publicly trusted certificates and manually renews publicly trusted certificates. Let's all sit in a lunchroom together with a beverage and talk turkey. Here it is.

Tim CallanI'm really glad you suggested this, Jay, because one of the things you and I sometimes discover is there's stuff that we both take for granted because we live so deeply in this world that we don't explain it. And it is valid to say, listen, people who don't live as deeply in this world can maybe not have these thoughts or not engage with this in this way and why do we do our podcast if not to help people have these ideas? And so, I think it I think it was overdue, and I think it was an excellent suggestion, and I'm really glad we had this conversation today.

Jason SorokoThank you, Tim. Thank you. So to all of you out there who do the hard task of making the internet work at the command line, probably of Linux or something else like it, Tim just laid out six reasons for sure - not just one or two - six undisputably good reasons, and this seventh reason is all about you. And some of you have exclaimed to us, isn't this just a money grab from the CAs? The answer is, we're not, Tim taught you. Tim taught you that we're going to be renewing certificates every 30 days, essentially, with the 47 day certificates. And there's no way it's not going to be some kind of subscription program where you can purchase one year's worth of certificates and renew whenever you need to, probably every 30 days. That's the reality of it. You won't be paying any more than you do now.

Tim CallanThis isn’t a scheme for the CA to nick you for 12 times what you are paying now. That's not what it is.

Jason SorokoThe only reason we would sell you an individual 47 day certificate is because you absolutely needed it to get your job done.

Tim CallanI actually think those will be available in the market for what it's worth, but I don't think they'll be the norm.

Jason SorokoI'm not. No one should ever be encouraged to just go off and buy a one-off unless they absolutely had to.

But now let's talk about sitting at the command line. Let's talk about sitting at your beloved Linux command line. Look, guys and girls, I know you. I know you. I was one of you. Okay? I still am one of you. And I can tell you right now, if you're not embracing automation right now for every aspect of your job, then you're doing the wrong thing for yourself and the company you're working for.

You're just doing the wrong thing. The right thing is to say to yourself, I'm going to let a computer do this renewal, and my job is going to be to make sure that that renewal happened correctly. And Tim just taught you - you renew every 30 days, and you've got that sweet two weeks of being able to deal with it, with whatever happened. That's why Apple wrote into the proposal what they did. So I don't care how you automate this out. There's so many technologies that are out there. Just pick one and take yourself out of the process. Believe me, there's not an enterprise in the world right now that doesn't value you. You are rare. You are needed, and sitting at the command line doing a manual renewal and manual tracking doesn't make you important. Get yourself out of the business of manual renewals. Please.

Tim CallanI don't have the episode numbers in front of me, but Jason and I did a whole series on this as well. Where we talked about why you as an IT professional are better off using automation, and why you as a manager of IT professionals are better off using automation. Two episodes back to back. Those are worth going back to and looking at as well where we go into depth on this.

Jason SorokoSo Tim, I have a flip side to this, which is that's my impassioned plea to people who sit at the Linux command line. I also have a plea to people who are the risk officers, the C-levels, people who own the risk in an enterprise. Too many of you who are on the board at the C-level and own the risk, too many of you let this problem get figured out by your Linux administrator. Well, it's a technical problem. I'm going to let my technical people sort it out. No, this is a risk problem, and you own it, and therefore we didn't end up solving the Y2k problem 24 years ago because of the fact that the C-levels just let their technical people sort it out. No. It was because C-levels and the Board said, we have to solve this. This is a gigantic risk to everything, including my organization that I'm responsible for. These changes to shorter certificate lifespans that have all the reasons that Tim stated above are vital to the way the WebPKI works. You as a C- level are part of that, and you have to encourage the use of automation amongst your staff.

Tim CallanAnd you can do things your staff can't. You can approve budget. You can remove roadblocks. You can manage up. You can help with strategic partnerships. You can put pressure on vendors. These are all things you can do that that that Sys Admin cannot.

Jason SorokoThat is why we have to talk to the C-levels and the Board and people who own risk because you are as much part of this as the people who do the hard work at the command line. This involves everybody. So folks, when you see Apple with their proposal that Tim in a previous podcast spelled out the, the what, we're now saying, the why in this podcast. And I would say very strongly, this isn't big tech companies putting an oppressive weight on your shoulders for no reason. There is tremendously good reasons for all of this. Please automate.

Tim CallanAbsolutely. This is not these guys just deciding to flex their power or be big meanies. This is technically astute people who understand the ecosystem and have a very clear vision of what needs to happen for it to remain secure and get more secure.

And then the other thing, if you want to take away from these seven items that we listed, is the level of commitment to shortening certificate lifespans that you see in places like the browser vendors is very, very high. Don't view this as a passing fancy or something kind of lightweight and diaphanous that they're just going to forget about. This is a very deep conviction that has an organized, rigorous effort over the span of years, and that's how you want to think about this.

Jason SorokoHere’s an interesting final thought from me, Tim, is for those of you who are in the publicly trusted certificate renewal business - in other words, for those of you who sit at that command line - while you're having lunch, go talk to the folks, the prestigious men and women in your organization who deal with the private trust side of your business, and talk to them about the certificate lifespans in their business and what they do. I guarantee your DevOps folks are dealing with certificate lifespans in hours. Never mind 47 days.

Tim CallanOr even a day or two, but not more than that.

Jason SorokoAnd for most of the reasons, most of the same reasons that Tim and I talked about earlier in this podcast. There's an interesting conversation for all of you to go and have.

Tim CallanI agree, Jay. So that's our list. That is, I, we will keep returning to everything on that list in the future. We've referenced all those things somewhere along the line. We'll keep right on referencing those things because they're very important motivators, and I'm glad we did this episode today.

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!