Root Causes 442: Apple Proposal to Reduce SSL Lifespan Updated

Hosted by

Tim Callan

Chief Compliance Officer

Jason Soroko

Fellow

Original broadcast date

November 25, 2024

Apple has published an updated draft to its proposal for shortening the lifespan of SSL certificates, including a final maximum term of 47 rather than 45 days. We explain.

Podcast Transcript

Lightly edited for flow and brevity.

Tim CallanWe discussed in our Episode 432 about Apple's proposal as a potential CA/Browser Forum ballot to step down the duration, the term, maximum term of a public TLS certificate ultimately, to what at the time was 45 days. We have an update on that, and we want to go over that today.

Jason SorokoLooks like there's a minor change, but it's important to note.

Tim CallanI think there's a few subtle changes. Apple has posted, the original poster, has put a new repo up on GitHub with some modifications from the original thing. This is I think directly in response to feedback, and we talked in Episode 432 about how when I looked at the original proposal, I already felt like that was something that was accounting for the feedback that had been received from the March 2023 suggestion by Google that we go down to 90 days. You saw that feedback accounted for. We now have accounting for some of the additional feedback that's come in since the original repo and this is the process doing what it's supposed to do. This is the whole point of it. So maybe we'll start out, let's quickly reference the differences, and then walk through what the new proposal looks like, and then we can talk about it a little. Does that make sense?

So two meaningful changes from the original proposal. There's actually a third change, but the first meaningful change is that the maximum term, instead of sitting at 45 days, now sits at 47 days. And I believe the rationale here is that on every one of the stepdown periods - remember, it stepped down to 200 which is six months plus a little, then it stepped down to 100 which was 90 days plus a little, then it stepped down to 45 which was one month plus a little. And I think the point there was to make it more than two weeks longer than the longest possible month. So a month could be up to 31 days long. So if you're on a monthly schedule, you may need 31 days to stay on your monthly schedule. 31 days plus 14 is 45. That's exactly two weeks longer. Apple wanted you to get something more than two weeks so that you weren't going to run into any problems and 45 didn't get there. They just moved it to 47. I think from the security of a cert perspective, if the concept is that shorter certificate terms are better, 47 is two days longer than 45 so by that line of reasoning, it's less than 5% less secure. I think they felt like this is a fine trade off in terms of the security, in order to give people more opportunity not to have this be disruptive.

Jason SorokoIt completely makes sense, Tim. I'm more convinced than ever that what's probably going to go through most people's minds - They probably see that that number of 45 or 47 and think how strangely arbitrary. It's not arbitrary at all. It really is meant for people to signal to them that renewing their certificate every 30 days and with a minimum of a two-week grace in case there's an issue with the renewal, is exactly what's being intended here.

Tim CallanRight. I agree. So that's change number one is going from 45 days to 47 and, we might as well use the right number. So from here on out, we'll talk about 47 days, not 45 days, because that's the real number.

The second change, which is possibly the more meaningful of the two is that the dates are moved out. So you may recall that September 15, 2025 was the original announced date for stepping down to a six-month to a 200-day term. That has now moved out to March 15, 2026. So March 15, 2026 we step down to 200 days. Exactly a year later, March 15, 2027 we step down to 100 days and then in 2028, a year later, it's actually April 15, 2028, we step down to 47 days. That is the process there.

So really just everything has been pushed out by a quarter. Everything's been pushed out by whatever that's going to be, or, I guess, two quarters. Everything's been pushed out by five months. And that is something that I was always expecting. I'm not sure whether or not we covered this in our Episode 432, but in my mind, I always felt like September 15 was going to come too fast, and that those dates were going to wind up being moved and I'm not at all surprised to see that move occur. I feel much more confident in March 15 as a real date that the industry might really stick with.

Jason SorokoSince this is going to a ballot proposal - it is a proposal for a ballot - I think when it comes to the ballot, it makes it a little harder to say this is too soon. I think with the change in the date, it actually helps it to become more attractive and make sure that people are a little more ready. This whole 200-day stepdown, you and I talked about it in previous communications out to the internet, I think that it's a really interesting in the middle kind of a date where the hope is that most people will already be automating their renewals but for those that just simply can't, they can limp along with every six months. I think that's the idea.

Tim CallanI think it's great. I think for exactly the reasons you said. It's this perfect Goldilocks zone, where it's long enough that for systems and environments that people have to do it manually, they can, but it's short enough that it goes a long way into achieving the other objectives of things being more secure, of there being a closer alignment of domain ownership with certificate ownership and that it's motivational for the industry to move to automation and people to adopt automation. It’s great. Folks who already complain about doing this once a year are not going to be sanguine with doing it every six months, and it will help people prioritize these items in the roadmap. It will put pressure on vendors to support ACME or other automation options. It will put pressure on the people who control budgets to give the budget necessary for tools or projects to move over to automation. All of that stuff is going to come with six months. So we're going to get those benefits. But, at the same time, somebody who just simply can't do this right away because they have other priorities, because they have legacy systems, or because they're putting pressure on a vendor to support ACME, those folks can muddle through if they have to, and they will muddle through, but they'll be motivated to fix it. So the six month stepdown, I think is great.

I also think it's great that there is a clear progression beyond that. If it was just about to move to six months, then we'd move to six months, and then we'd all know, people are going to get used to six months, and they're going to work out their way to do it every six months. They're not going to really solve it. But even if you're going to get through with six months, that's temporary, because a year from now, it's going to go down to three months. So, you're motivated to fix the problem and view the six month step as a temporary stopgap measure if you're doing it manually, not as the new normal. So in that regard, I think it's all terrific.

Jason SorokoWe have this intermediary period. You're going to get the full value of 90-day with a 100-day certificate, and then for 47 day, you get that little bit of an extra grace period that might mean a weekend or some kind of a period like that. So, these changes are subtle, but I think what we're finding, Tim, is we're getting really close to what I think the final thinking is going to be on this. All the thinking so far has been really rational.

Tim CallanAbsolutely. I agree. What you said is right, again, when I look at all of this, and we'll get into the DCV reuse stepdown and the OV reuse stepdown well, because all three of these things are included in this ballot, but when you look at the whole ballot holistically, the one thing I keep seeing is I keep seeing somebody who has considered every aspect of it, and everything here is considered. Nothing is knee jerk or thoughtless, or sloppy or phoned in. Everything has been considered, and whether or not you agree with it. I think it's hard to argue that these aren't deliberate choices that are based on some kind of reasoning.

Jason SorokoTim, this is all good. I'm just going to take the moment that we have right here before we get into the rest of the changes and some of thinking. I'd like to propose on what you just said for people who are balking at some of this. I think we should have a podcast very soon about addressing some of the objections and about the entire concept and really explain why this is happening, and I know we've done podcasts like that in the past, it’s just it'd be good to refresh it.

Tim CallanI think that's a really good point. Let’s do that for sure. So look for that one. Listeners, keep your eyes peeled for that one.

Now the next one they change is they change the DCV reuse period. So as I mentioned, and this is one of the things we'll get out in that podcast you just described, Jason, but there is a desire to see the closest possible alignment between domain control and certificate ownership? That's one of the big things that TLS certificates are here to do and to the degree that those are misaligned, TLS certificates are just not doing their job very well. If you look at today's situation, there's a 398-day DCV reuse period and a 398-day maximum certificate term.

So in principle, in theory, I could get a new certificate, do DCV on that certificate, and give up the domain the next day. Sell it, let's say. At which point, I don't own the domain, and then 397 days later, I could order a new certificate for 398 days, and it would be 26 months later between when I gave up control of the domain and when my last validly issued certificate expired. A certificate that was not misissued. I think the browsers are just saying, come on, this is ridiculous. This is just absurd.

Jason SorokoIt is absurd. For those of you who are long term holders of domains, which is a lot of the audience. A lot of people who work for enterprises, you have your brand, you have your domain, you own it for probably forever, and yet, you don't think about things like this, but this is the world that we live in. It's the world that the browsers live in and the CAs live in, and a lot of people flip domains constantly, and this does need to be mitigated.

Tim CallanThe DCV reuse period is going to mirror what we see in the certificate term. Today it's 398 days. On March 15, 2026, it drops down to 200 days - exactly what the certificate term is. A year later on March, 25 2027, it drops down to 100 days - exactly what the certificate term is. Then in 2028 instead of dropping to 47 days - this is where it's different - it drops directly to 10 days. That's the other difference. The original proposal had a step down to 45 and then later in the year, a stepdown to 10. I think as part of the compromise of pushing everything back, the 10-day stepdown was kept where it was. So as of April 15, 2028, you're going straight to a 10-day step down.

Jason SorokoI'm just thinking out loud about the meaning behind 10-day just to give people a reason to think about that and if we lived in a perfect world, we would go down to a DCV per issuance model, and that means, like, to the moment.

Tim CallanThat might occur eventually.

Jason SorokoI think it might. But I think it's this grace period, just like, just like the term of 47 days for the maximum certificate lifespan, 10 days for maximum DCV. The way to think about it is the industry really does want to go to a DCV per issuance model, but they're giving you that 10 days for now as a grace period. It'll probably be around for a while before we go down to per issuance, but that's where we're probably headed.

Tim CallanA DCV per issuance model, I think requires really pure 100% automation. You need to get to a point where there is pure 100% automation before that is viable, especially since in that circumstance, the maximum certificate term will be 47 days, and that might be going down too. So if I have to manually DCV every month, that's much harder. So if I'm ordering a flight of certs, if I need to get five certs, and I order those five certs today or over the course of the next couple days, then I don't have to do DCV every time Now, the 10 day - Why 10 days? There's been this crystallization around 10 days as an interesting goal for a shorter term cert and this shows up in a couple ways. One way it shows up is that there is no revocation checking required right now, according to the CA/Browser Forum rules for any cert that is not longer than 10 days in term. So if I'm offering 10 day or less certificates, I do not need to offer either OCSP or CRL. I can just plain not have a revocation checking mechanism in place, and in so doing, the idea is that certificate expiration is a surrogate for revocation. And there's something wrong with the certificate. The next certificate doesn't have that problem, and that that 10-day window is something that we're all willing to live with. Now that is, as it happens, exactly the same number that we see here. It feels like there's alignment on certain periods and certain numbers, which I think is good for the industry.

The other thing I'll point out again is that the DCV reuse period is matching. It goes, right now it's 398 then both the certificate and the DC reuse at the same time go down to 200 and then they both at the same time go to 100. I think that's about just simplicity of rules. One thing is complicated regulations and complicated rules are easier to get wrong, and they're easier to get wrong unintentionally, just because you made it harder to comply and by matching those up, there is less opportunity for people to get confused about, okay, wait, how many days is DCV and how many days is term? When they're QAing it and when they're writing the code, it's just less opportunity for there to be error. I also view that, when I see that, as a considered decision where Apple looked at the holistic situation and said, look, CAs are going to have to comply with this. They're going to have to build in checks. They're going to get audited against it. They're going to have manual procedures. They're going to have software-based checks, and all of these things are going to be more likely to be gotten right if we keep these numbers the same. So what the heck? Let's just keep them the same.

Jason SorokoFor those of you who are curious, Tim, I think it's worth pointing out this, this coalescing around 10 days in Root Causes Episode 272 titled OCSP’s Privacy Problem, you and I got into a lot of detail around that original proposal around 10-day certificates.

Tim CallanTerrific and just one thing is now that is actually an action. I think, when you and I talked about that, that was a proposal. When you go back and listen to that episode, if you do go listen to that episode, that's now the case. Like that is the policy.

And then the last one to be cognizant of is there's a reduction in OV reuse period. And so this is the only one that didn't really change, except for the date. The OV reuse period today is 825 day. That's organization validation. That's the stuff about the company.Who are you and where are you located, and stuff like that. That period right now is 825 days, which is two years plus a little and it will go down to 366 days, exactly one year in the longest possible year, starting March 15, 2026. Then in that proposal, it just stays at 366 days from there on out.

The rationale behind that, again, it's matched up at the same time, March 15, 2026. So all the requirements change at once. All the step downs occur at the same time. Keeps it simpler. It's going down to one year because organizations just don't change as fast as things like domains do, and organization validation is heavier than DCV. It's harder on the subscriber and the CA both. I think there's a rationale here, which is to say, look, one year works fine. We're pretty current on what the org is. It gets updated every year because remember, the certs at that point are going to be not more than 200 days long, and they're going to go down from there. So as the certs go down, the opportunity for organization misalignment just goes down and down and down.

Jason SorokoIt's all good. Like I said at the top of the podcast, a lot of these changes are really subtle, but you're seeing a true circling in of what makes an awful lot of sense, especially for something that'll eventually be voted on.

Tim CallanSo that's where it stands right now. Again, this is a draft that is open for commentary, both from the public and from the members of the CA/Browser Forum. I think there's a recognition at Apple that this is one of the big moves, and it's a big move, and they want to ensure that everyone has a chance to say their peace. I will say that the public commentary mostly hasn't surprised me, and I still feel like this is a strong draft. I feel like this will definitely go to ballot, and I don't know if it'll pass a ballot, and if it doesn't pass the ballot, it'll be interesting to see what happens, but I feel very confident this is going to ballot.

Jason SorokoI can't wait to see. Tim, this is really a great update. I know I've personally been asked a number of questions about this whole topic. I think you covered it really well on this podcast. So thanks for that.

Tim CallanThank you, Jason, and there will be more developments here and listeners, we will definitely let you know when that happens.

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!