Root Causes 108: Why Do Certificates Expire?

Episode Transcript

Lightly edited for flow and brevity.

• 

  Tim Callan

  Today, you and I wanted to talk about – well, a little bit of background. So, as we podcasted not very long ago, there was a root expiration for one of our legacy roots and we talked about what happened around that and some of the dialogue that I’ve seen online that came out of that is well, why do these things expire at all. So, I think you and I wanted to talk today about why do certificates expire?

• 

  Jason Soroko

  That’s a good question because wouldn’t it be easy if you could just carry around these things forever and then you don’t have to manage them.

• 

  Tim Callan

  Yeah. Expiration is awful. Expiration is every single certificate is like this ticking time bomb and the day I deploy it in my environment there’s going to be some time in the future where if I’m not watching it it’s gonna ambush me. It would be like imagine if there was something you had around your house – bath towels. Imagine if bath towels after 50 days burst into flame and you had to run and get them at 49 days and throw them out and put down a new bath towel. We’d all say these are terrible. Let’s get different bath towels, right? But that’s basically what certificates are doing to us and so it causes a lot of angst for people and so, you know, gee, gosh, there better be a real good reason for this. And obviously, there is, but I think we want to talk about what that is today.

• 

  Jason Soroko

  That’s a good way of putting it, Tim. It is absolutely a ticking time bomb, but we do this for good reasons and isn’t it interesting that we can sit down here and ask yourself well, why are we doing this to ourselves but if we take a look at the trends, the trend is in everything from public trust to private trust. In all aspects the trend is toward shorter lifespans rather than longer, Tim.

• 

  Tim Callan

  Right. Yeah. The certificates are expiring sooner and sooner. There’s less time before the time bomb blows up. So, you know, at a fundamental level like what are the reasons for expiration. It’s about – well, you might be tempted to say it’s really about security and it is about security, but I think there are a couple of other important benefits as well. But let’s start with security.

• 

  Jason Soroko

  That’s the one that’s closest to my heart, Tim, especially on the private trust side.

• 

  Tim Callan

  So how do you see the security thing?

• 

  Jason Soroko

  Sure. So in other words, there was in the earlier, earlier days of PKI with IoT, for example, IoT devices really you were just trying to enable an authentication mechanism or perhaps a signing function, you know, some basic function that this device was gonna do throughout its life and the device was made, manufactured, or put out into the world in such a way that it really could only do one or two things and it was never gonna do anything else. It had very little capacity to be upgraded, updated, or anything and so therefore, the renewal of a certificate because of a certificate expiry, that whole concept was just not possible. And so, you had what was known as fire and forget certificates, which was a tongue and cheek way of basically saying a certificate would have been issued at point of manufacturing and it would just be in that device until the point at which it was discarded.

• 

  Tim Callan

  Right. For the lifespan of the device, at which point, the certificate lifespan becomes the maximum device lifespan, so you must make sure that the certificate lasts at least as long as you need the device to last. Right?

• 

  Jason Soroko

  That’s correct, Tim. And in fact, if that was a truly a rooted PKI-based certificate then the root mechanism needed to have perhaps an expiry of 50 years or 100 years, who knows. Some of these infrastructures especially, you know, smart meters come to mind. How long do these things sit on the side of a house or sit on the side of a commercial building. Could be decades.

• 

  Tim Callan

  Yeah. Nobody wants to go out and get them. Or even worse, I think an example we used earlier is, you know, what about something in a satellite, right. You are never getting that back ever. That’s it. There’s no getting the satellite back. The satellite is where it is and so that better be like that’s it. That’s gonna be the lifetime of that device is how long that needs to be but then also that represents a problem if that certificate lifespan is too long and I guess when we are talking about security, like what are the security risks with a certificate sitting around too long. One of them is that the cryptography just gets outpaced, and we’ve seen that, right. Where once upon a time we believed in SHA-1 now we don’t. Very soon we are not gonna be able to use RSA. So, the cryptography, you know, we had MD5 and now we don’t have MD5. Like the cryptography can be surpassed.

• 

  Jason Soroko

  Oh absolutely, Tim. There are all kinds of devices. We are talking routers. We are talking cable boxes. We are talking about all kinds of things that were physically manufactured years ago that have what would today be a deprecated cryptographic algorithm or hashing algorithm that’s included. But there’s also, Tim, the issue of the fact that these things, because they are physical, tangible things that don’t sit behind firewall, they’re out in the hostile world. I’m thinking of an automobile, for example. An automobile is sitting on the street with a vulnerable OBD port and perhaps there might be a way for the bad guy to go and retrieve that certificate.

• 

  Tim Callan

  Yeah.

• 

  Jason Soroko

  So, in other words, the private key, which is just so important to protect, may be potentially vulnerable and so therefore that automobile depending on what it’s doing with that certificate, you may not want to trust that certificate for the lifetime of the car. You may want to potentially shorten the lifespan of what the bad guy can do if they happen to physically obtain that certificate.

• 

  Tim Callan

  Right. Like there’s all kinds of IoT devices that are just sitting somewhere unwatched, right. Where someone with the right hacksaw could come long and cut that thing off of whatever it’s attached to, throw it in the back of a truck and drive away and then if they are able to work some kind of magic at home to break into it and get the private key then now, they have the private key. Absolutely.

• 

  Jason Soroko

  So, Tim, let’s push this even further. Like IoT is in just so many places and it’s just such a good example. Think about certificates in airplanes. Just for the purpose of broadband communication on a tarmac, you know, the communication of perhaps where are you and where am I to a catering truck on a tarmac just as one little example. I’m thinking here of the Aeromax consortium and some of their standards. They’ve made it such that every time an airplane takes off and lands it’s renewing a certificate because of the risk. It would just be so terrible if for some reason a bad guy were able to obtain that certificate, they could just play havoc on an airport tarmac.

• 

  Tim Callan

  Absolutely. Or worse, right. In the air. So, security is a big one and it’s about cryptographic algorithms. It’s also about key sizes. You know, if something sat around for 30 years and someone might be able to take an amount of compute power that right now, we can’t even think about and 20 years from now they might be able to use that and throw that against a key and find the correct combination and so for all these reasons, you know, you and I have had a lot of talk about terms. What’s too long or too short of a term but even then, there’s an assumption that there’s expiration built in there. Like without expiration the term is forever. So, you know, I issue a cert now and I’m saying, I’m making a statement that in 50 years or 100 years no one is going to be able to do something to break that cryptography and nobody can make that statement about anything cryptographic and that’s fundamentally the security reason why we need to have expiration and then it’s just a discussion about how much time is ok.

• 

  Jason Soroko

  That’s exactly right, Tim. In other words, is it possible – I mean we are talking about dramatic scenarios here, but we have seen it happen. What happens if the root CA unravels?

• 

  Tim Callan

  Oh yeah.

• 

  Jason Soroko

  Because of a breach of some kind. I mean in the public trust world it’s incredibly unusual especially amongst the mature CAs but in the private trust world, Tim, how many CAs just pop up. In other words, the whole concept of I want to be able to let this thing die and let it renew is important and regardless of the timeframe that you choose an absolute expiry. In other words, Tim, the ability to renew, the ability to issue from a new root is very, very important concept and so therefore, expiry is the fundamental aspect of that. If it can expire it then therefore needs to renew.

• 

  Tim Callan

  So, you are touching on an important point here, right, which is that it’s not just end leave certificates that expire. It is also intermediates. Those are certs and what we normally refer to as roots or root certificates. Those are certificates too and those must expire too. Now the intermediates and the roots and then there are sort of what I’ll call infrastructural certificates like timestamping certs and OCSP certs and things like that are certs for parts of the infrastructure and they tend to have different durations, different timeframes. And all of these things I’ve just discussed, these infrastructural kind of certs, have longer timespans than the leave certificates do because they have to for the system to work but they can’t go on forever either. For all the same reasons we discussed.

• 

  Jason Soroko

  That’s exactly right, Tim. It’s just fundamentally, fundamentally in my mind the reason why you need to have expiries. And there’s a ton more than this but really what it comes down to is you do need to have some mechanism to allow a trust to stop because you may want to reissue. You may want to reissue for any number of reasons. Some of which might have been a security breach of some kind, or you mistrust something now because there’s some level of risk.

• 

  Tim Callan

  Yeah. You must renew it every so often. So, it’s a similar thing where like I access my work email on my phone and every so often the way my IT department has set it up, they make me reauthenticate and it’s not every day but they do it. And the idea is that it’s just a risk mitigation thing. Hypothetically, if my phone got on the wrong hands and I didn’t know it. For some reason, I’m in the hospital in a coma and some bad guy got my phone and nobody is aware of that fact there is a limit on the amount of time that the bad guy can do the bad thing before it stops working. And so, it’s kind of that idea that it’s good to build these systems where every so often you just must go back and just reestablish that this is really what you want to be doing.

• 

  Jason Soroko

  Tim, there is a part of me as well that wants to bring up the topic of the principle of least privileges because this isn’t the whole part of it, but it is a piece of it. A chronological piece of it. We had a great podcast not that long ago with the DevOps practitioner. We talked about two-hour certificates for DevOps and you might wonder, well, that is the greatest pain in the butt I’ve ever heard of. Why in the world would I do that to myself? Well, there is really good reasons for it because that certificate once issued allows you, if you possess it you are able to then authenticate into a pretty sensitive system and you have privileges to do certain things if you possess this certificate. So therefore, once it is issued you really don’t want that thing to last any longer than it needs to because who knows where it could go. Who knows, you know, if there’s some sort of man in the middle attack going on, somebody then possesses it that shouldn’t and any number of flaws or vulnerabilities that could happen won’t stop the initial attack of the bad guy. If the bad guy gets it immediately and starts doing something with it in the first few minutes, well, you have problems. But you don’t want that bad guy to have it for a year.

• 

  Tim Callan

  Yeah. And why wouldn’t you reduce that damage, right? I’m reminded of the Equifax data breach. One of the things about the Equifax data breach is that it went on for like 70 days where they kept harvesting data because they could. If they had had a two-hour time window, the amount of damage they did would have been much, much smaller. And yeah, so exactly. The reason to have that two-hour DevOps cert is that once the utility of that cert has gone to zero no matter how unlikely it is that it’s misused, once the utility of the cert is generally at zero, then the arithmetic is against you having that cert sitting around. So, you might as well not. Now you could have these things revoked and you might be able to revoke them automatically but on the other hand if they just expire that’s more foolproof that revocation. So why wouldn’t you do that.

• 

  Jason Soroko

  And revocation is costly.

• 

  Tim Callan

  Yeah.

• 

  Jason Soroko

  Revocation requires bandwidth. It requires a lot of work. So therefore, short lifespans take care of that for you.

• 

  Tim Callan

  Yeah. And let’s say there is a software error, because we know software error happens and the automatic revocation mechanism isn’t firing, right, but expirations are still expirations and they are just gonna expire. There’s no getting around it. So alright, I think all of that is important. In addition to security, there’s a couple of other things that come up and I think the next biggest one is crypto agility and this is tightly related to security and we alluded to this earlier in the podcast but, you know, if we are gonna be using deprecated algorithms or we are gonna be uses key sizes that too small or we are gonna be doing something else that is no longer considered to by hygienic PKI having built-in lifespans forces all that stuff to get renewed and if every year, which it’s soon gonna be a year, all of your SSL certificates need to be swapped out then that means in the event that there’s a practice that is identified as being insecure or in-ideal in a worst-case-scenario it’s around for a year and then it’s gone and that’s better than being around for two years or five years or nobody knows how many years and so this concept of agility definitely comes up a lot and it certainly was one of the motivators for leading browsers to want to move from two-year certs to one-year certs in the SSL space. And then the other one that again also certainly applies in the world of SSL and probably anywhere where there is identity factor is changing identities. So in the case of SSL I can sell a domain name. So, I can have a cert for a domain I don’t own. Now it’s hard to see what the attack is but you sort of say, well, let’s just, you know, if all of those certs have to age out and they don’t exist anymore then that little bit of cleanup is done for us and I think if there were another PKI scenario where ownership or control of what the cert is identifying might change, let’s say, you know, I leave my job and I give my work-assigned laptop back and they give it to another employee for instance. Then again, the more time-limited those certs are the better you are from avoiding any kind of mismatch between what the cert says it’s identifying and what it’s pointing at.

• 

  Jason Soroko

  That’s another thing that’s difficult to manage over longer periods of time.

• 

  Tim Callan

  Exactly. So, once again, just unthinkingly, you and I have fallen into a conversation about how long these certs should be and where we started was, well not infinite, right? And we keep coming back to not infinite and again, I think it’s great to have a dialogue and it’s fine for people to say is it really ok for a root cert to last for 20 or 30 years and – topic for another podcast but the answer is yeah, really it is and kind of it’s gotta be. But, either way, not infinite. We are still starting from the place of not infinite.

• 

  Jason Soroko

  It’s interesting, Tim, cause during this podcast we did bring up the difference between root, intermediate and leave certificates and perhaps a podcast coming up for those people who are interested in this, how in the world can you have a 20-year root certificate, for example, and maintain the safety of that because we’ve talked about risk over and over here. Security risk. Well, how do you mitigate that security risk? And that’s a good - -

• 

  Tim Callan

  That’s a great podcast. Let’s do that.

• 

  Jason Soroko

  That’s a podcast in terms of HSMs and etc. because there are ways to do it.

• 

  Tim Callan

  Yeah. I think that’s a great one. Let’s cover that for sure. Alright. So maybe enough said. Any more thoughts on this, Jay? Or did we get them all out there.

• 

  Jason Soroko

  I think this is a topic where anybody who is interested in this subject it’s great for a cold summer beverage, right, to sit and talk about this but I think we’re mostly covered here today.

• 

  Tim Callan

  I agree. We just wanted to cover it. Sometimes these fundamental assumptions don’t get discussed and there’s good reasons for them, like back when people were making these decisions in the day, there were reasons, and this is a great example of that. So, with that, thank you very much as always for an interesting conversation, Jason.

• 

  Jason Soroko

  Thank you.

• 

  Tim Callan

  Thank you, listeners. This has been Root Causes.