Safari to Reject HTTPS Certificates Longer Than a Year
Last week, at the 49th CA/Browser Forum, a voluntary consortium of certification authorities, Apple announced that it’ll stop allowing HTTPS certificates on Safari with more than 13 months of validity, later this year.
[…]
As the Register noted, sites like GitHub and Microsoft have certificates with two-year validity. Under Apple’s new rule, these sites will be rejected if these companies will get another two-year certificate after August.
The rationale? Shorter certificate lifetimes are safer, for a variety of reasons. For one thing, it prevents a valid (and perhaps abandoned) certificate from being stolen or misappropriated by a bad actor, then used to trick consumers. While there is a process for revoking known bad certificates, it’s cumbersome and many browsers don’t even check the revocation lists.
For another, quick turnaround helps ensure that the certificates are always secured using the latest cryptographic standards.
[…]
The major downside for certificates that expire more often is that it means more work for organizations that have a large number of certificates that they will now need to renew more often.
[…]
At least one previous proposal to reduce the life of accepted certificates has been put to the CA/Browser Forum, but while it was widely supported by browser makers, it didn’t garner enough support from Certificate Authorities to make any head way. So Apple, in its own tried and true fashion, has apparently decided to make a unilateral change for what it believes is the best for users.
Previously:
Update (2020-03-06): Apple:
TLS server certificates issued on or after September 1, 2020 00:00 GMT/UTC must not have a validity period greater than 398 days.
This change will affect only TLS server certificates issued from the Root CAs preinstalled with iOS, iPadOS, macOS, watchOS, and tvOS.
The complaints I’ve heard regarding Apple’s move to 13 month or less TLS cert validity are perfect examples of why the current validity window is too damn long.
For example, “Before, I could completely ignore my site’s security for 5 years and then forget to renew!”
Catalin Cimpanu (via Rosyna Keller):
Google wants to reduce the lifespan of SSL certificates (used to secure HTTPS encrypted traffic) from the current two years to just over a year.
Which brings me to the second point: certificate renewal should be automated and that’s something that you simply can’t do once identity verification is required. DV is easy and indeed automation is a cornerstone of Let’s Encrypt which is a really important attribute of it. I recently spent some time with the development team in a major European bank and they were seriously considering ditching EV for precisely this reason. Actually, it was more than that reason alone, it was also the risk presented if they needed to quickly get themselves a new cert (i.e. due to key compromise) as the hurdles you have jump over are so much higher for EV than they are DV. Plus, long-lived certs actually create other risks due to the fact that revocation is broken so iterating quickly (for example, Let’s Encrypt certs last for 3 months) is a virtue. Certs lasting for 2 years is not a virtue, unless you’re coming from the perspective of being able to cash in on them...
See also: Accidental Tech Podcast and Rich Trouton.
Update (2020-06-11): Dean Coclin:
Chrome joins Apple in limiting public TLS certificates to 398 days starting Sept 1st.
6 Comments RSS · Twitter
I wonder how this applies to self-signed certificates, and whether there will be a similar override mechanism to allow them to be trusted. Private devices (like Arduinos and such) often have self-signed certificates for example, and having a short expiry time on them would not necessarily be pleasant.
It's a bad thing. Tools are supposed to work in all conditions, because that way they are more useful. Instead, corporations now feel that they can throw their weight around, and decide how everyone should behave, regardless of the pain they inflict on the purchasers of their tools, or on the third parties that run websites. Compatibility matters, something Microsoft forgot in the days of IE's dominance. Instead, Google and Apple have clearly grown too large for their boots, and need to become humble again, the way Apple was when it first introduced Mac OS and Microsoft was the bully in town. Time for the EU to apply some anti-trust regulation if the US won't.
IE's dominance was problematic because it made people depending on the whims of one company.
Safari is neither dominant (yet just big enough to somewhat keep Chrome in check), nor is this particular policy change one that will harm anyone. On the contrary, it is motivated by improving security.
As for companies that rely on longer certificates: the way this news broke to me is actually through our certificate reseller. They wrote me a nice letter not to worry and that for multi-year certs, they'll simply create a second certificate for free after twelve months.
@Philippe no its a bad thing. It increases work and failure modes while doing nothing to increase security. We've had this debate with password length.
Security is not achieved by adding more layers like certificates, it's achieved by reducing the attack surface -- i.e. the complexity of the wall between the attacker and the valuable data. Meaningful hacks like that of Equifax were not due to "out of date" certificates. They are due to too much complexity in the stack. Adding new types of certificates only adds complexity since new software has to be added to make that functionality work.
It is actually a good thing for everybody
https://scotthelme.co.uk/certificate-lifetime-capped-to-1-year-from-sep-2020/