In the early days of the encrypted web you could get certificates valid for any period of time. Long gone are those days and as more time goes by we realise just how much we need to be doing a lot more to greatly reduce the maximum validity period on certificates for a whole bunch of different reasons. Here's why.
The history of certificate validity periods
In the beginning a CA was not limited in what validity period it could place on a certificate that it issued. Back in the late 2000's GoDaddy would quite happily issue you a certificate that was valid for 10 years! Imagine that, never having to renew, no process, no hard work. You could just install it and forget about it for close to a whole decade! There are quite a few examples of these certificates out there so I grabbed just a few from Censys, you can see them here, here and here. If you'd like to see the whole search and more examples you can find them here. Whilst this seems like a great idea it really isn't, and for a great many reasons that I will go into, but first, I want to bring us up to date on where we currently stand in terms of certificate validity periods.
The first restrictions on the maximum validity period of a certificate came with the introduction of the CA/Browser Forum and their Baseline Requirements document. The 'CAB Forum', as they're commonly called, is the body that governs how CAs must issue and manage publicly trusted certificates through the rules set out in the Baseline Requirements (BR). If we go all the way back to the very first version of the BR, which was adopted on 22 Nov 2011 and effective from 1 Jul 2012, we can see the introduction of that first limit. Section 9.4 of that very first document states:
Certificates issued after the Effective Date MUST have a Validity Period no greater than 60 months.
This was the first limit placed on the CAs but even the 5 year certificates were not to be long lived. To keep GoDaddy happy at the time, the 5 year limit was introduced but it will soon be dropped to 39 months instead.
Except as provided for below, Certificates issued after 1 April 2015 MUST have a Validity Period no greater than 39 months.
Almost 3 years from the introduction of the first version of the BR, the 5 year maximum age was already going to be dropped to a little over 3 years. Since that date in April 2015 we have lived with a maximum validity period of 39 months on our certificates until recent efforts were made to reduce the maximum validity period further.
Current certificate validity periods
In Feb 2017 the CAB Forum voted on a ballot proposed by Ryan Sleevi of Google to reduce the maximum validity period of certificates to just 398 days, a tremendous step forwards in the security of the web. Sadly, that ballot did not pass and was met with wide resistance from all but one of the CAs that voted. Here are the votes:
Voting by CAs – 25 votes total plus abstentions
1 Yes vote: Let’s Encrypt
24 No votes: DigiCert, Entrust, AS Sertifitseerimiskeskus, Izenpe, ANF Autoridad de Certificación, Comodo, Certinomis, HARICA, GlobalSign, Quo Vadis, GoDaddy, Actalis, Symantec, Trustwave, CFCA, Secom, TWCA, GDCA, Certum, OATI, Buypass, SHECA, CNNIC, Cisco
3 Abstain: Logius PKI, SwissSign, Chunghwa Telecom
Voting by browsers – 4 votes total plus abstentions
2 Yes votes: Google, Mozilla
2 No votes: Microsoft, Qihoo 360
1 Abstain: Apple
Given the failure of the ballot to reduce the maximum age to 398 a new ballot was proposed in March 2017 to try and reduce the maximum age to 825 days instead. This ballot was successful with the following votes:
Voting by CAs – 27 votes total including abstentions
24 Yes votes: Entrust Datacard, TurkTrust, Izenpe, Certinomis, DigiCert, Amazon, CNNIC, HARICA, GlobalSign, GDCA, Disig, Trustwave, Let’s Encrypt, Quo Vadis, SHECA, CFCA, OATI, Comodo, Buypass, Logius PKIoverheid, Cisco, Symantec, Certum, SwissSign
0 No votes:
3 Abstain: ANF Autoridad de Certificación, Secom, Actalis
Voting by browsers – 6 votes total including abstentions
5 Yes votes: Apple, Qihoo 360, Microsoft, Opera, Google
0 No votes:
1 Abstain: Mozilla
From March 2018 that means that all newly issued certificates will be limited to a maximum validity period of 825 days! This is a great step forwards for the security of the wider web and my hope is that another ballot will be put forward later this year to try and reduce the maximum validity down to 398 days again. Perhaps the small step to 825 days will be enough to encourage a further reduction, we can only wait and see. With that said, and having given a clear view on where we currently are with certificates, let's take a look at why we need to reduce the validity period on certificates and what benefits doing so would bring.
Why we need shorter certificates
At first it seems like shorter certificate validity periods would be nothing more than a pain, having to renew them more frequently, but there are some serious security benefits to reducing the lifetime on the certificates you get.
Revocation is broken
Revocation is the process by which you stop an attacker being able to use your certificate after they've stolen your private key. If I manage to steal the private key for a paypal.com certificate, or they accidentally publish it to GitHub like DJI (the drone maker) did recently, I can now use that certificate to prove I am paypal.com, intercept/decrypt traffic and get green https in the address bar. That's a really bad place to be and we need a mechanism to stop that happening, that mechanism is revocation. Unfortunately though, Revocation is broken. We're not just talking a little broken either, go and read the blog I just linked, it's completely broken. In the event of me stealing the private key for the paypal.com certificate, there's basically nothing that PayPal can do to stop me using it. The only real defense they have to try and protect themselves and their customers is to get certificates with a shorter validity period.
Think about the difference between a 3 year and 3 month certificate. I manage to break in and steal the private after 1 month of you obtaining your shiny new certificate. With the 3 year certificate I now have 2 years and 11 months with which to abuse that certificate and cause harm. That's 2 years and 11 months where visitors can visit paypal.com, see green https in the address bar and maybe not even be talking to PayPal or have a secure connection... Not good. Now think about the 3 month certificate though. If I manage to steal the private key for that 1 month after you get it, as the attacker I only have 2 months to abuse the certificate before it expires. This forces me to act more quickly, I now have a much shorter time frame in which I'm a threat and overall your users will face a considerably reduced amount of risk.
Flushing the ecosystem
There have been changes in the wider certificate ecosystem just as you'd expect in any complex ecosystem. New fields are introduced to certificates, old fields are deprecated, acceptable values change and especially when related to encryption where we have to constantly adapt to new threats and more capable adversaries. There are some good examples of things like this happening and the maximum validity period of certificates being a concern, the most recent was the SHA1 deprecation.
CAs used to use the SHA1 hash algorithm to generate the signature on certificates. The signature is what gives a certificate all of its value and is how the browser can validate the document is from a trusted CA and that it hasn't been tampered with. The problem was that SHA1 got older and weaker until eventually it was inevitable that it would be broken. In Ballot 118 in October 2014 the CAB Forum decided that from 1st Jan 2016 no CA would be allowed to issue a certificate signed with SHA1 and SHA256 must be used instead. That's fine and we have our deadline but the problem was that browsers weren't going to wait long enough before they stopped accepting SHA1 signed certificates. Chrome announced that from 1st January 2017, at the latest, they would stop accepting SHA1 signed certificates and other browser vendors were right behind them in their deadline too. It's a good job too because literally a couple of months after that, SHA1 was broken.
That meant you could get a 39 month long certificate on 31st December 2015, valid until March 2019, that wouldn't work beyond January 2017... The 39 month validity period was too long and didn't give the industry enough time to react to new developments and attacks, which meant that sites had valid certificates that would stop working before they expired.
The SHA1 deprecation isn't the first time this has happened and it certainly won't be the last either. We've seen other changes like the move from 1,024 bit RSA keys to 2,048 bit RSA keys and the recent move by Chrome to deprecate the Common Name field require sites re-issue certificates before they expire. There are constantly new threats that as a wider industry we need to respond to and 39 months was just far too long to wait, we need to be able to flush the whole ecosystem of all existing certificates much faster.
Key rotation
The expiration of a certificate provides a great opportunity to rotate the key that's in use with that certificate. Outside of a natural renewal of an expired certificate you'd have to have a certificate re-issued prematurely if you wanted to rotate the key, which is far more unlikely. Outside of the use of HTTP Public Key Pinning, which I recently gave up on and Chrome has announced they're deprecating, you should rotate your private keys at least every year. With a 39 month, or even an 825 day certificate, we're realistically going to see keys rotated at most at those intervals and not before. This is bad hygiene and the longer a given cryptographic key is in use the more likely it is to face compromise, I'd much rather see a push towards ephemeral keys than static keys wherever possible.
CT log disqualification
Whilst this isn't an issue right now, it will become something worth considering over the next couple of months when we see the introduction of a new requirement in Chrome for all certificate to be 'CT Qualified'. Certificate Transparency is an awesome new requirement that should be landing in April 2018 that will require all CAs to log all certificates they issue into public and audtiable logs. This means that we will have full transparency into the operations of any CA, these hugely powerful organisations that are effectively the gatekeepers to encrypted communications online, and no one will be able to obtain a certificate for your domain without your knowledge. To be CT qualified a certificate has to contain at least 3 Signed Certificate Timestamps from 3 independent logs. If a certificate does not contain 3 valid SCTs then it won't be considered as CT Qualified and the browser will reject it. If a certificate log is disqualified during the life of a certificate then that would invalidate the SCT inside the certificate from that particular log and that could well drop it below the CT qualification criteria.
Now, a CA can offer some protection against this by placing several SCTs in the certificate to hopefully withstand a disqualification, but the problem still stands. The longer a certificate is valid for, the more likely it is a log disqualification could happen and that the certificate would fail CT qualification and be rejected. Shorter certificates help to protect against this being a problem and it's also a lot safer to include less SCTs in a 90 day certificate than it is in an 825 day certificate, making it smaller too.
Things you do regularly, you do well
Imagine that you had to a do task only once every 5 years, how well do you think you'd remember the steps involved? Would it be fresh in your mind or would it be some vague, distant memory of a thing you did in 2013? One of the things I've seen more and more of recently is expired certificates being served up on big websites.
When you're literally in the middle of delivering The Best TLS Training in The World where we teach people how to use the awesome @letsencrypt and renew certificates automatically, LinkedIn come along and demonstrate why it's *so* important! pic.twitter.com/rjThqwGofu
— Scott Helme (@Scott_Helme) November 30, 2017
Now I'm sure there are often just genuine errors and oversights but I've heard so many stories of companies where they simply forgot. Someone bought a cert, it expires in well over 3 years and that's a date that's a long way away, it gets forgotten. Not only that but when the renewal comes around, no one can remember that process we had to go through, who did it, how they did it or where the documentation is. Make renewals part of a regular process and they will soon become one of those tasks that you just do and don't even need to 'think' about. But, you know what's even better than that? Automation.
Automated certificate renewal
One of the things that I absolutely loved about Let's Encrypt was not that they were a free CA but that the renewal process could be completely automated. Don't get me wrong removing the cost barrier was a massive thing for so many people, but I was already happy to pay for certs. For me, the far more important but often less talked about benefit of Let's Encrypt is how you can obtain certificates. I've talked about Let's Encrypt a lot, my getting started guide, my cool emoji subdomain 🔒🔒🔒.scotthelme.co.uk, ECDSA certificates, my smart renew script and much more.
Despite all the cool stuff I do with Let's Encrypt the absolute best thing will always be that with a single cron job I can automatically renew all of my certificates and not need to worry about a single thing. Heck, I even do it from my Ubiquiti home network equipment! Let's Encrypt only issue 90 day certificates and if you were renewing manually that'd be a pretty big concern. We want frequent renewals but as you get more certificates it becomes harder to do it manually, this is why automation is essential and why I will continue to drive and push automation to everyone I speak to and train. Remove the risk of missing a renewal, remove the risk of human error, reduce the cost involved in obtaining and renewing certificates. What's not to like? I appreciate that right now it may not be a viable option for everyone but the whole concept of automated renewal is brand new to pretty much everyone. This is only going to get better and easier as time goes by. There will be more tools, more services and more offerings to help you with this so maybe not today or next week, but it's certainly on the horizon.
When your CA is naughty
This one is admittedly a much smaller concern, yet still something that can happen. Right now we're seeing the wider distrust of Symantec as a CA and sites are having to replace certificates before they expire yet again. You could quite easily have a 39 month certificate from Symantec that will stop working less than a year after your purchased it.
I recently wrote about the Symantec distrust and you can see that there are still quite a large number of sites who may hit issues in April and then September if they don't take action and replace their certificates very quickly. I'd bet it'd be a lot easier to replace certificates if it were a regular part of your process and not some odd procedure that you go through every 3+ years instead!
We are going in the right direction
We genuinely are and I'm really happy to see the progress being made on not only encrypting the entire web, but the reduction in certificate lifetimes as part of that. As we issue more and more certificates across the web the issues above are only going to become more and more relevant to more and more sites. If you're looking to start out and deploy HTTPS to your site, now is the best time to do it and do it right. Go for short certificates, look at automating as much of the process as possible and give yourself the best start. If you have been using https for a long time, maybe with 39 month certs, perhaps now is the time to look at replacing that old process with something newer, faster, easier and cheaper. We need to continue accelerating the web towards https and continue driving down the maximum allowed validity period on certificates, but that doesn't mean you have to get certificates with the maximum validity period, you can always choose to get shorter certificates too.
EV Certificates
One other point to touch on here is that you might hit issues with EV certificates. Now, I've touched on EV certificates before where I asked Are EV certificates worth the paper they're written on? and ultimately the answer is no, for a whole bunch of reasons that I cover in that post. But, focusing on the purpose of this post, EV certificates are inherently working against almost all of the points outlined above. EV certificates are hard to get, there's a whole long process invovled in getting one, so people want to try and avoid doing that wherever possible. This forces people to choose longer validity periods on their certificates to avoid that hard process. This is not the direction we want people to be heading, towards longer certificates. Not only that though, the CAs actively encourage people to purchase longer validity periods with discounts and now sites have a financial motivation to do the wrong thing too.
The other problem with EV certificates is that they're anti-automation. The human process required to get an EV certificate, coupled with the many hours or even days required to complete it, means that there's no way to automate it. You're going to have to continue to obtain and manage these certificates manually and that just doesn't scale. If you need to quickly rotate your keys and certs after a compromise, this is also going to work against you. Overall we're seeing a push to much shorter lived cyrptographic secrets, ephemeral keys are preferred for good reason and the harder we can drive down their life expectancy of they keys we use, the better.