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 of 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.
OCSP is an internet protocol used to verify the real-time validity status of a certificate and serves as an alternative to Certificate Revocation Lists (CRLs). OCSP performs instantaneous checks on certificate status, playing a pivotal role in the architecture of Extended Validation SSL certificates.
When a user establishes an HTTPS connection with your web server, their browser typically conducts an OCSP check with the Certificate Authority (CA) that issued the SSL certificate to ensure it hasn't been revoked. This process may occasionally introduce a brief delay during the SSL handshake.
OCSP Stapling optimizes performance by incorporating a digitally-signed and time-stamped OCSP response directly into the web server. This stapled OCSP response undergoes regular updates at intervals specified by the CA. As a result, the web server can seamlessly include the OCSP response within the initial SSL handshake, eliminating the necessity for the user to initiate a separate external connection to the CA.
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
OCSP Stapling offers several advantages for SSL handshake efficiency and user privacy:
- Accelerated SSL Handshake: OCSP Stapling streamlines the SSL handshake process by consolidating two requests into one, significantly reducing the time required to load an encrypted webpage.
- Enhanced User Privacy: This technology preserves the privacy of end users by avoiding direct connections to Certificate Revocation Lists (CRLs) for OCSP requests. As a result, CA servers only receive OCSP requests from the web server itself, eliminating the visibility of individual user browsing histories.
- Accessibility in Specific Scenarios: In certain scenarios where a computer must connect to a portal or hotspot to access the internet, OCSP checks may be challenging due to limited internet access. OCSP Stapling proves beneficial in these cases, as the OCSP status is supplied directly from the hotspot or portal, ensuring a smooth connection process.
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.”
Disadvantages of OCSP Stapling
While OCSP Stapling offers several advantages, it's important to be aware of its potential disadvantages:
- Increased Server Workload: OCSP Stapling requires the web server to periodically fetch and update OCSP responses from the Certificate Authority (CA). This can increase the server's workload, especially if there are frequent updates or a large number of certificates to manage.
- Implementation Complexity: Setting up OCSP Stapling correctly can be complex and may require additional configuration on the web server. Administrators need to ensure that the stapled responses are regularly updated to reflect the current status of certificates.
- Compatibility: While widely supported, OCSP Stapling may not be compatible with all clients or browsers. Some older or less common clients may not properly handle stapled OCSP responses, potentially leading to issues with certificate validation.
- CA Dependency: OCSP Stapling relies on the CA's OCSP infrastructure. If the CA experiences downtime or issues with OCSP responses, it can impact the SSL/TLS validation process for websites using OCSP Stapling.
- Resource Utilization: Fetching and updating OCSP responses can consume network and server resources. In cases of high traffic or resource-constrained servers, this can have an impact on overall performance.
- Potential for Misconfiguration: Misconfigurations in OCSP Stapling settings can lead to security vulnerabilities or improper certificate validation. It's crucial to ensure proper setup and monitoring.
Despite these potential disadvantages, OCSP Stapling is widely used and can significantly enhance SSL/TLS performance and security when implemented correctly. Organizations should carefully weigh the benefits against the potential drawbacks and consider their specific use case and server environment before implementing OCSP Stapling.
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.
(This post has been updated. It was originally published on Mar 16, 2020.)