Blog
Welcome to the Hardenize blog. This is where we will document our journey as we make the Internet a more secure place and have some fun and excitement along the way.
Update (1 September 2020): As of today, certificate lifetimes are restricted to 398 days. Ballot SC31 of the CA/Browser Forum, passed on 16 July 2020, formally adopted the changes described in this post and incorporated them into Baseline Requirements.
Apple have changed the rules their software uses in deciding which certificates to trust. Certificates issued from 1st September can have a lifetime of only up to 398 days. From that point in time, certificates valid for longer periods will not be trusted at all. We are updating Hardenize to detect affected certificates as soon as they are published to Certificate Transparency.
To understand why Apple have done this, it’s worth thinking about some context. Technologies change over time. Lessons are learned about how they work, in how real world usage compares to that envisaged by designers. Flaws are discovered. Enhancements are adopted.
PKI is no exception. Much has been learned about what works and what doesn’t in the 25 or so years since the Web started using the technology. One area where change was needed is around the certificate lifecycle; the specified mechanisms for revoking certificates were unworkable and the maximum permitted lifetime of certificates was too long. Because of this, browser vendors have been pushing for shorter certificate lifetimes.
Some of their efforts have been successful: With the CA/B forum’s adoption of the Baseline Requirements (effective from 1st July 2012), the validity period of certificates was limited to 60 months. In April 2015, a clause in the Baseline Requirements came into effect which further limited the maximum lifetime of certificates to 39 months.
Some efforts were less successful; two attempts to reduce the maximum lifetime of server certificates to one year were rejected by the CA/Browser forum, mostly due to opposition by CAs. The argument that certificates with shorter lifetimes are more secure is generally accepted, but CAs are exposed to pushback from their customers, who are used to renewing manually and at longer periods.
Browser vendors point out that shorter lifetimes are helpful for a number of reasons. The main problem is that certificate revocation remains broken (though Mozilla are still pushing hard to resolve this). Browsers typically do not check for revocation information at present. Certificates with shorter lifetimes are less affected by this problem. In addition, more frequent replacement of existing certificates also allows older standards to be phased out faster and with less disruption.
On the other hand, CAs have some different concerns: CAs make the point that many of their customers prefer less frequent renewals because they rely on manual processes. Because of this, the increased renewal frequency imposed by shorter certificate lifetimes makes more work for them.
This is a valid concern, but it’s also true that many of the drawbacks associated with shorter certificate lifetimes drive good practice; decreased reliance on manual processes reduce both the likelihood of human error and the work associated with renewal. Many organisations already do this for resilience and scale. (Google, for example, rotate their certificates every 3 months).
In March, Apple forced the issue by announcing that they will reduce the maximum allowed lifetime of TLS server certificates. Apple devices running recent versions of their respective operating systems will not trust certificates issued from September 1st 2020 that have been issued with a lifetime longer than 398 days (these certificates will not be trusted at all; they will not even be valid for the first 398 days of their validity).
There’s no change to the Baseline Requirements (Apple’s action was unilateral - the CA/B forum did not agree to this change) so CAs can continue to provide certificates with longer lifetimes if they want to so long as they accept that not all users will be able to make use of servers which rely on them. This change does not apply to certificates issued from local (user or administrator added) roots.
We are not aware of any announcement being made by Google yet (they supported the proposal the last time the issue was voted on at the CA/Browser forum). This Chromium commit shows that Chrome (and other browsers based on Chromium) will follow Apple’s lead (this change also does not apply to local roots).
There has been a discussion on Mozilla’s dev-security-policy list about this issue; it resulted in a proposal to change Mozilla’s PKI policy. Related, Firefox does not currently enforce existing rules on maximum certificate lifetimes).
There has been no official word from Microsoft yet. Since current versions of Edge are based on Chromium, Edge users may benefit from the Chromium change. It is unclear at this time whether any changes will be made to other Microsoft products (Internet Explorer, platform HTTPS implementations).
To address the changes to allowed certificate lifetimes, we're updating Hardenize to detect and alert on certificates valid for more than 398 days.
More interestingly, we will be extending our Certificate Transparency monitoring to validate every new certificate as it appears in the logs, providing real-time alerts should any certificates appear to be affected. This check will be enabled by default. With this approach we will be able to provide immediate notification as well as comprehensive coverage of all certificates issued to our customers.
The most likely outcome is that this change will be handled by CAs and that you won't have to do anything, except that from September you won't be able to purchase certificates valid for more than a year. To be sure, you should reach out to your CAs of choice for a statement of what they're planning to do. According to the information available so far, internal certificates should not be affected.