Certificate Lifespans - What to Know
Here’s something that caught my attention recently. Many years ago, some SSL certificates were valid for eight years. A few were even valid for ten years. That’s a terrifying thought to me. If a cyber attacker acquired those machine identities, there would be years and years worth of data in danger! Some of these certificates were even used in the early days of ecommerce in the late 90s. So that would be an awful lot of credit card accounts in a cyber attacker’s hands.
But on the administrator’s end, certificates that are valid for several years can sound like a dream. There would be much less work that they’d have to do. And they’d work with much fewer certificates overall, making manual certificate management a lot easier. Unfortunately, the things that make manual certificate management easier are terrible for the security of your networks and applications. It’s that old security versus usability axis. And the recent explosion in the use of TLS certificates pretty much makes manual certificate management impractical.
The CA/Browser Forum often makes decisions that could have drastic effects on the security of your web applications. The Forum consists of all the major web browser developers, including Apple, Firefox, and Google, and more than forty different certificate authorities. They come together to make decisions about policies and procedures pertaining to TLS certificates. As Scott Carter wrote here recently, Google wanted to limit maximum certificate validity periods to a year. But many of the CAs didn’t like the proposal because they were concerned about the additional certificate rotation burden on their customers.
Apple Limits Certificate Validity Period
But during a CA/Browser Forum meeting in February, it appears that Apple has found their own way to limit the validity time period of certificates in order to make TLS more secure. iPhones and iPads have sold like hotcakes for the past several years. Safari is the default web browser on those devices, of which I estimate about half a billion to a billion are currently being used worldwide. There are lots of MacBooks in use, and Safari is popular there, too. So, Apple has the power of dominant market share to influence their own standards. They’re now using it to announce that as of September 1st 2020, Safari will no longer trust certificates that are valid for more than 398 days. That’s a year and a little bit, eh? Apple can’t control what the other Forum members do, but they can totally control Safari.
That’s generally a great move as far as web security is concerned. But of course, there will be headaches when administrators have to make sure that their websites and web apps are compatible with Safari’s new standard. And everyone involved will have to follow suit.
These sorts changes to TLS validation period standards will continue as time goes on. They’re inevitable. The ways that TLS is implemented will continue to change. Your strategy for managing TLS machine identities should be ready to handle it in the years to come.
Should you get free and easy TLS certificates through Let’s Encrypt to adapt to the change Apple made? If you want your website or web app to enjoy maximum trust on the client end and have optimal security, Let’s Encrypt might not be the best idea. Let’s Encrypt doesn’t offer Extended Domain Validation certificates. Let’s Encrypt does provide TLS certificates that web browsers can accept, but they’re not the most trusted type of certificates. Your users will see it in their browser’s UI. So how can your organization adapt to much greater demands on certificate generation and keeping all of those machine identities secure?
What is OCSP Stapling?
One very useful feature you could use is OCSP stapling. I’ll gladly explain what that is.
Certificate Revocation Lists (CRL) used to be a common thing in the world of SSL implementation. Each time a client, such as a web browser, needed to access a website with SSL, they’d download a copy of the CRL from the CA so that the client software could check to see whether or not a particular certificate was revoked. That system didn’t scale well with the massive growth of the web and shorter certificate lifespans, leading to certificates having to be issued, revoked, or expire with much greater frequency. Enter OCSP. The Online Certificate Status Protocol makes it possible for a client to submit a request to a CA to determine whether or not a certificate has been revoked. But if CA infrastructure is poor, OCSP on its own can be unreliable. And it’s probably not good for security for clients to share more data with CAs than is absolutely necessary.
That’s where OCSP stapling comes in. It’s fun for me to visualize! I can imagine all kinds of boxes being sent through a warehouse and onto delivery trucks. The waybill could have packet header data and a copy of a public key. A website makes a request to its CA, and the CA’s response is “stapled” onto that metaphorical waybill. So, it’s not the web browser that’s making the request, it’s the web server. The client’s privacy is better protected, and the OCSP process can be made to be more efficient.
Advantages of OCSP Stapling
Scott Helme explained some of the advantages of OCSP stapling:
“The big problem that we had with revocation checking was that we couldn't rely on it. CRLs were bad, OCSP endpoints were unreliable and stapling helped but we didn't know if the site supported it. Now we do. In the event of a compromise or any other scenario where you find yourself needing to revoke your certificate you can be confident that when the client receives your certificate in a connection it will be forced to check for a stapled OCSP response. This offers a huge level of protection and reduces the potential time an attacker can abuse a compromised certificate from the maximum life of the certificate, which could be up to 39 months, down to the maximum life of the last valid OCSP response, which could be a few hours.”
The ways that TLS is implemented will continue to change. Manual certificate management is obsolete and unworkable with the new reality of much shorter certificate lifespans. Automated machine identity management is clearly the way to go, and features like OCSP stapling can make it easier to make sure revoked certificates aren’t ever used.
Related posts
