Podcast
Root Causes 73: Apple to Drop Support for Two-year SSL Certificates
Hosted by
Jason Soroko
Fellow
Original broadcast date
March 13, 2020
At the most recent Face-to-Face meeting of the CA/Browser Forum, Apple announced that as of September 1 it will distrust public TLS certificates issued with terms longer than thirteen months for all its technology products. Join our hosts as they discuss this change, its affect on the ecosystem, and what you need to do to prepare for one-year SSL certificates.
Podcast transcript
Lightly edited for flow and brevity.
TCTim CallanHow are you doing today, Jay?
Jason SorokoDoing fantastic, Tim, but I am worried that our lifetimes are getting shorter. By that I mean support certificate lifetime.TCTim CallanThey are indeed.
So, we have talked about certificate lifetimes in the past and shortening certificate lifetimes and so following up on that conversation, that ongoing thread there certainly was big news from Apple at the latest CA Browser forum face-to-face meeting where essentially Apple announced that moving forward starting on a certain specific date, it was only going to honor one-year public SSL certificates.
So, we have talked about certificate lifetimes in the past and shortening certificate lifetimes and so following up on that conversation, that ongoing thread there certainly was big news from Apple at the latest CA Browser forum face-to-face meeting where essentially Apple announced that moving forward starting on a certain specific date, it was only going to honor one-year public SSL certificates.
Jason SorokoSo, this is not from a ballot, Tim. This is from Apple basically unilaterally deciding which is moving the industry. Is that right?TCTim CallanThat’s correct, Jay. So, the way most things happen at the CA Browser forum is that ballots are passed and then everybody must honor the ballots because those are the rules of the forums and they follow historically two bodies of rules, which is what they call the baseline requirements or the EV guidelines and there are soon to be some guidelines for code signing and there may be other things in the future. But the other way that things can happen is that browsers that control their own root stores decide what they are going to do with certificates can just plain announce rules. And CAs must follow those rules if they want their certificates to be honored in the browsers. And this has happened on a few occasions over recent years and this is the most recent of those occasions; where Apple just said this is what we are doing and if you want us to see your certificates, your certificates are gonna have to comply.
Jason SorokoThat’s interesting, Tim. I would say the initial reaction I have to that is of course, you know, I live on the private side of the world where certificate lifespans are shortening quite a lot. We heard not that long ago from Dave Colon, a practitioner in DevOps and he has got certificates down now to two hours in some cases. So, therefore, 390-something days, which I guess is 13 months is what we are talking about here for now the new lifespan of the certificate. The way it was solved in the private trust side of the world is through automation and I would imagine that this new shortened lifespan on the public trust or SSL side of the world where people are dealing with web servers, the solution is gonna be the same thing.TCTim CallanYeah. I think so. So, you hit a bunch of good points there that we should probably unpack. So, let’s start with what they announced. So, it’s 398 days and 398 days you might say, well that’s an interesting number. That’s a very specific number. So, 398 days, if you go as follows.
If you take a normal year, you add a day in case it’s a leap year. So, you are up to 366 days and then you add the longest possible month, 31 days, now you are 397 days. So, the way I interpret this is it’s the longest possible interpretation under any circumstances of the concept of 13 months plus one day. And what that means is that CAs essentially can offer 13-month certificates.
So, it’s a common practice in the public certificate world to allow somebody to renew early so they don’t have this crisis where they are trying to swap out the cert the same day it renews, but people are notoriously cheap, right, Jay? So, one of the things that they do is they wait until the last possible instance to renew their certs and that creates problems. So, what CAs have had as a practice for a long time is, they allow early renewal. And what early renewal means is I will make the new cert terminate one year after the end of the cert that you are renewing, and I’ll give you those extra days. Those 15/20 days, whatever it is, and that gives you an opportunity to install the new one while the old one is still running so you don’t have this crisis. And, so, you know, certainly Apple obviously respects the value of that practice and has left that in place, has made it possible for any CA to say, ok, I’ll give you your cert is due on the 21st, the next one will be due on the 21st, right? That’s basically the idea. Give it up to one month early and with that number of days you can do that plus you have one more day for padding, so you don’t have any worries about time zones or things like that. So, that seems to me what Apple is up to with that, and it seems to be a very well-considered, carefully considered and I would say correctly arrived at, number of days and it shows us a couple things.
One is it shows us that Apple thought this through carefully. It shows us that Apple was paying attention to how these things were really used and it shows us that Apple is trying to do this in a way that is as minimally disruptive to subscribers as possible. So, those are three good takeaways.
This is how we like to see browsers take unilateral action when they do. Often, they do it that way very carefully and responsibly. Sometimes they don’t, but we really like it when they do, and this is a good example of Apple getting it right.
If you take a normal year, you add a day in case it’s a leap year. So, you are up to 366 days and then you add the longest possible month, 31 days, now you are 397 days. So, the way I interpret this is it’s the longest possible interpretation under any circumstances of the concept of 13 months plus one day. And what that means is that CAs essentially can offer 13-month certificates.
So, it’s a common practice in the public certificate world to allow somebody to renew early so they don’t have this crisis where they are trying to swap out the cert the same day it renews, but people are notoriously cheap, right, Jay? So, one of the things that they do is they wait until the last possible instance to renew their certs and that creates problems. So, what CAs have had as a practice for a long time is, they allow early renewal. And what early renewal means is I will make the new cert terminate one year after the end of the cert that you are renewing, and I’ll give you those extra days. Those 15/20 days, whatever it is, and that gives you an opportunity to install the new one while the old one is still running so you don’t have this crisis. And, so, you know, certainly Apple obviously respects the value of that practice and has left that in place, has made it possible for any CA to say, ok, I’ll give you your cert is due on the 21st, the next one will be due on the 21st, right? That’s basically the idea. Give it up to one month early and with that number of days you can do that plus you have one more day for padding, so you don’t have any worries about time zones or things like that. So, that seems to me what Apple is up to with that, and it seems to be a very well-considered, carefully considered and I would say correctly arrived at, number of days and it shows us a couple things.
One is it shows us that Apple thought this through carefully. It shows us that Apple was paying attention to how these things were really used and it shows us that Apple is trying to do this in a way that is as minimally disruptive to subscribers as possible. So, those are three good takeaways.
This is how we like to see browsers take unilateral action when they do. Often, they do it that way very carefully and responsibly. Sometimes they don’t, but we really like it when they do, and this is a good example of Apple getting it right.
Jason SorokoThat’s a lot of really good information there, Tim. I really think that you must consider that you have well over 100 million domains right now that are on 90-day certificates, and they are working quite well. They are not having downtime problems because they are using automation one of those, you know, public protocols being used of course being ACME and there are others out there as well. What are some of the arguments people are making to not have this one-year or to continue with the two-year? Because I’m sure that there is some pushback and I’m sure there is some legitimate reasons, but, you know, how do to respond to that?
TCTim CallanThis has been an ongoing debate at the CA Browser Forum for a long time and in recent years two ballots were proposed to limit the duration of certificates to one year and they both failed, and they failed because a majority of CAs voted against them. So, full disclosure, SE22 which came up last summer, which would have been a one-year certificate ballot, we voted in favor of, but the majority of CAs voted against and their argument is that this is onerously difficult for the subscribers. That essentially you have just doubled the amount of certificate management work that they need to go through and therefore they are going to be much more likely to have an outage or a problem and the amount of work that they have to put in just increased dramatically.
Now, the response to that is - - response number one is like what you said, Jay, how about automation? And then the argument sort of goes, well, you know, not everything is automatable so if you are a born-in-the-cloud, five-year-old tech company, you probably build everything from the ground up in a way where this is no problem for you. But if I am a legacy business and, you know, I’m in some non-technology field and my company has been around 150 years and I’ve still got things somewhere in the world running on Fortran then it’s maybe a lot more difficult to go in and make these kinds of changes and to say we can’t just go retrofit our systems to all be automated so quickly and so overnight. So, this debate goes back and forth.
Now, the response to that is - - response number one is like what you said, Jay, how about automation? And then the argument sort of goes, well, you know, not everything is automatable so if you are a born-in-the-cloud, five-year-old tech company, you probably build everything from the ground up in a way where this is no problem for you. But if I am a legacy business and, you know, I’m in some non-technology field and my company has been around 150 years and I’ve still got things somewhere in the world running on Fortran then it’s maybe a lot more difficult to go in and make these kinds of changes and to say we can’t just go retrofit our systems to all be automated so quickly and so overnight. So, this debate goes back and forth.
Jason SorokoSo, Tim, I’m aware – in fact, I’m quite aware of a lot of the minutia of some of the complexities that happen at the web server and load balancer level that could cause that kind of an argument for sure, but I’d like to then split out a little bit of cultural issue from what might be reality. I’m absolutely certain there is some percentage where somebody is gonna pull their hair out and say hey I just can’t automate this and I’m still working off a spreadsheet. There is always gonna be a 1% of that somewhere, but I would say that culturally there is a generation of Linux administrators out there that just are paranoid and do not want to let go of control and you and I have talked about this before, Tim. We endorse that. Being paranoid in a security business - -TCTim CallanIt's great.
Jason Soroko- - it’s what you must be by definition.TCTim CallanAbsolutely.
Jason SorokoBut, on the other hand, your risk officers and your CSOs and everybody else, I don’t care what size of business you are, your web property shouldn’t go down because of an expired certificate.TCTim CallanYeah, and there is that risk too. So, I appreciate saying, gee, I worry about the set it and forget it mentality and I want to make sure that I have my hands-on things personally. Yeah, but on the other hand, human error occurs. Right? Or humans and unforeseen things happen. Somebody goes on vacation and gets injured and can’t come back for six months and the hand-off doesn’t happen properly, or somebody suddenly gets a new job, and the handoff doesn’t happen properly, and these things happen too. So, it’s not that cut and dried.
Jason SorokoEspecially, Tim, when you consider that the ACME protocol which is not an expensive or complicated thing to implement is build right into the latest version of Apache, which is a very large percentage of the web servers worldwide. So, therefore, I think again its culturally people have been doing certain things a certain way for so long they may not realize the toolsets that are available to them. Even if you are very small shop the ability to automate this is a lot less onerous than it was even not very long ago and for larger enterprises, well, you know, come take a look at the commercial offerings that are out there. I don’t want to be too self-serving, but we can help.TCTim CallanRight. Yeah. Yeah. Yeah. I mean you and I know this very well because we provide this kind of things to customers all over the globe. So, you know, from an automation perspective, if you are in the SMB side there is two main roots forward for you. One is that you use a protocol like ACME. There are others. And you do your own development, and you do your own automation, and a lot of people do that. The other one is you basically buy a platform that does it for you. Right? And subscribe to a platform that will do that for you and someone took away that programming work and did it on your behalf. If you are on the SMB side, you may not be aware but there is an alternative called subscription SSL. How subscription SSL works is you just sign up for several years that you want to have SSL coverage on this domain and then your hosting provider will basically automatically update your certs on a regular time period according to your subscription. So, once again, it can be taken away from you and you don’t have to worry about it anymore and these are great alternatives that cover both ends of the spectrum so that really all businesses ought to be able to instill automated approach to their TLS certificates.
Jason SorokoYou know, Tim, what I’m thinking right now is for anybody on either side of this – I don’t want to call it argument - it is what it is now but if you are troubled by this, reach out and get ahold of us. In fact, if you want to talk about your situation on this podcast even, I think we might be happy to talk with you and for everybody else, if you are having luck with certain kinds of technologies, I mean we are technology lovers on this show and we love to hear about how you are solving this if you’ve got a novel way of doing it. We certainly have our own. We’ve talked about ACME and others but if somebody else has their own ideas we are happy to hear it but certainly, I can’t harp on this enough because this is where I live but on the private side this has been inevitable since day one. Short lifespans are a good idea. A lot of websites around the world are down to 90 days. So, if you are still hung up on between two years and one year, it better be because of a very special situation technology-wise.TCTim CallanSo, we talked about the arguments against it. Let’s talk about the arguments for it.
Why do this? Why did the browsers do this? And it’s really three things. The first one is the point you are making, Jay, which is that all else being equal a shorter-lived certificate is more secure. More secure just like - - do a thought experiment with me. Let’s suppose on day 87 of the certificate’s life span someone manages to steal your private key and you don’t know about it. Well, if you have a 90-day cert they have three days to exploit it. If you have a one-year cert they have nine months to exploit it. If you have a two-year cert, they have 27 months or 33 months to exploit it. Right? So, in that sense - - sorry 21 months to exploit it. Bad math, Tim. In that sense, the amount of time, right, the amount of jeopardy with a cert just goes up over time and imagine like what if a cert was issued to a wrong party and nobody knew and etc., etc. So, for all those reasons shorter-lived certs are just considered to be less dangerous.
The second one which I don’t think is very important, but it is a thing is this idea of a domain certificate ownership mismatch. So, let’s say I own a domain. Domain names change ownerships. So, if I own a domain name. I know I own Tim.com, and I go buy a two-year cert for it and then I don’t renew Tim.com tomorrow and somebody else goes and picks it up or I sell that domain. Now what happens is I have a nearly two-year long cert that’s authentically issued off an authentic trusted root for a domain that I don’t control. Now I’m not worried about it because I have trouble understanding what the attack is. It’s not like I’m going to go out and get my juicy high value target domain and then go sell it to the exact person I want to attack and then use my cert to do my man-in-the-middle and somehow get away with all these shenanigans. Like it’s not a real-world scenario but it bothers some people.
And then the last one, which I also think is valid is the argument about crypto agility and the argument basically goes as follows. Look, there are some people who just aren’t going to swap out their certs. It doesn’t matter. We saw this with the Debian flaw. We saw this with SHA-1. There are some people, it doesn’t matter how many times you tell them or how many ways you tell them, they just don’t swap out their certs and by limiting the maximum life span of a public cert of a cert type you are limiting the maximum life span of a particular flaw that must be gotten away from and therefore you’ve improved your crypto agility and I do think there is validity to that as well. So, you know, those points are the ones that are always advanced by the browsers and then again, the, look, you are really hurting subscribers for what are theoretical concerns is what’s always advanced on the other side.
You know, we feel that it was just a matter of time that progress had been made, a lot of progress was made, and more progress was going to be made and somewhere along the line we had to pick a point in time to make the change and this was a good point. But Apple has taken it out of the CA Browser Forum’s hands and now we are all just going to do it because we need to work with Apple’s technology stack.
Why do this? Why did the browsers do this? And it’s really three things. The first one is the point you are making, Jay, which is that all else being equal a shorter-lived certificate is more secure. More secure just like - - do a thought experiment with me. Let’s suppose on day 87 of the certificate’s life span someone manages to steal your private key and you don’t know about it. Well, if you have a 90-day cert they have three days to exploit it. If you have a one-year cert they have nine months to exploit it. If you have a two-year cert, they have 27 months or 33 months to exploit it. Right? So, in that sense - - sorry 21 months to exploit it. Bad math, Tim. In that sense, the amount of time, right, the amount of jeopardy with a cert just goes up over time and imagine like what if a cert was issued to a wrong party and nobody knew and etc., etc. So, for all those reasons shorter-lived certs are just considered to be less dangerous.
The second one which I don’t think is very important, but it is a thing is this idea of a domain certificate ownership mismatch. So, let’s say I own a domain. Domain names change ownerships. So, if I own a domain name. I know I own Tim.com, and I go buy a two-year cert for it and then I don’t renew Tim.com tomorrow and somebody else goes and picks it up or I sell that domain. Now what happens is I have a nearly two-year long cert that’s authentically issued off an authentic trusted root for a domain that I don’t control. Now I’m not worried about it because I have trouble understanding what the attack is. It’s not like I’m going to go out and get my juicy high value target domain and then go sell it to the exact person I want to attack and then use my cert to do my man-in-the-middle and somehow get away with all these shenanigans. Like it’s not a real-world scenario but it bothers some people.
And then the last one, which I also think is valid is the argument about crypto agility and the argument basically goes as follows. Look, there are some people who just aren’t going to swap out their certs. It doesn’t matter. We saw this with the Debian flaw. We saw this with SHA-1. There are some people, it doesn’t matter how many times you tell them or how many ways you tell them, they just don’t swap out their certs and by limiting the maximum life span of a public cert of a cert type you are limiting the maximum life span of a particular flaw that must be gotten away from and therefore you’ve improved your crypto agility and I do think there is validity to that as well. So, you know, those points are the ones that are always advanced by the browsers and then again, the, look, you are really hurting subscribers for what are theoretical concerns is what’s always advanced on the other side.
You know, we feel that it was just a matter of time that progress had been made, a lot of progress was made, and more progress was going to be made and somewhere along the line we had to pick a point in time to make the change and this was a good point. But Apple has taken it out of the CA Browser Forum’s hands and now we are all just going to do it because we need to work with Apple’s technology stack.
Jason SorokoTim, I tell you what? In listening to everything that you just delivered in this podcast, I am gonna take us off topic only for one last second before we call it quits just to say that’s a pretty information-dense podcast and there was a lot to unpack there. I think for some people you might have to listen to it twice just because there is so much, but I think if you really listened in you got both sides to the story and a very balanced response. That’s not to pat ourselves on the back. What I’m trying to say here, Tim, is I’m very sensitive to people’s time and a very information-dense podcast is something I like to listen to. So, folks who are listening I hope that’s what you are sharing with us here.TCTim CallanCool. So, let’s just throw a little more information density right at the end and we can wrap it up. So, a few other facts about this announcement.
Number one. The date that it takes place is September 1. So as of September 1, that’s when the 398-day requirement occurs and just to be clear that doesn’t mean that your two-year certificate that was issued prior to that is gonna stop working on September 1. What I mean by that is certificates issued on or after September 1 have this requirement. So, on August 31 if you can go get yourself a two-year certificate it will work for the full duration. That’ll be just fine. As of September 1, if you get a two-year certificate, it will stop working instantly. Not in a year. But now. So, that’s how they are running that and that is important because that means that everybody who has a two-year cert today or everybody who has been expecting to buy a two-year cert 60 days from now and that’s fully what they were expecting, you can keep going with your plans and there won’t be any problems. Just remember that deadline comes up on September 1 and your public CAs are gonna stop offering you those certs anyways. So, you won’t have much choice.
And then the other part that’s connected to that is, let’s be clear, this is for public TLS certificates only. Apple is not doing anything to S/MIME. They are not doing anything to code signing. They’ll still have the three-year allowed durations that they have today and if you are using your own root and you are using private TLS certificates, you can do whatever you want with them. So, it’s just the public TLS certificates that Apple is putting this restriction on and this does apply to the entire Apple technology stack - iOS, Mac OS, iPad OS, the services, everything. So, the whole Apple shebang is tied to this behavior and this announcement.
So, take it very seriously. Those are your dates. Those are the things you need to know. If you need any clarification on any of this, we are very aware of what’s going on. We can tell you all about it if you just reach out to Sectigo.
Number one. The date that it takes place is September 1. So as of September 1, that’s when the 398-day requirement occurs and just to be clear that doesn’t mean that your two-year certificate that was issued prior to that is gonna stop working on September 1. What I mean by that is certificates issued on or after September 1 have this requirement. So, on August 31 if you can go get yourself a two-year certificate it will work for the full duration. That’ll be just fine. As of September 1, if you get a two-year certificate, it will stop working instantly. Not in a year. But now. So, that’s how they are running that and that is important because that means that everybody who has a two-year cert today or everybody who has been expecting to buy a two-year cert 60 days from now and that’s fully what they were expecting, you can keep going with your plans and there won’t be any problems. Just remember that deadline comes up on September 1 and your public CAs are gonna stop offering you those certs anyways. So, you won’t have much choice.
And then the other part that’s connected to that is, let’s be clear, this is for public TLS certificates only. Apple is not doing anything to S/MIME. They are not doing anything to code signing. They’ll still have the three-year allowed durations that they have today and if you are using your own root and you are using private TLS certificates, you can do whatever you want with them. So, it’s just the public TLS certificates that Apple is putting this restriction on and this does apply to the entire Apple technology stack - iOS, Mac OS, iPad OS, the services, everything. So, the whole Apple shebang is tied to this behavior and this announcement.
So, take it very seriously. Those are your dates. Those are the things you need to know. If you need any clarification on any of this, we are very aware of what’s going on. We can tell you all about it if you just reach out to Sectigo.
Jason SorokoWow. That’s a tight pack of information, Tim. You know, I’ll tell you what. Last response to this is I think this is a good move and I think it is inevitable.TCTim CallanI agree.
Jason SorokoI don’t know if it’s gonna get shorter than one year. Who knows? Maybe there will be a ballot in the future to push it down to 90 days or half a year or God knows what. But you can see where the trend is going and it’s not necessarily a bad trend, especially if we can get automation in every nook and cranny.TCTim CallanYeah. Agree. Certainly, we won’t see anything go shorter than one year, you know, this year.
Jason SorokoNo.TCTim CallanOr, in 2021, but certainly if you keep imagining the future, I could see that happening as well.
So, important news for the listeners. Thank you so much, Jay. As always, it’s a pleasure talking to you.
So, important news for the listeners. Thank you so much, Jay. As always, it’s a pleasure talking to you.
Jason SorokoThank you, Tim.TCTim CallanAll right. Thanks, folks. This has been Root Causes.
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!
