Sysadmins rage over Apple’s ‘nightmarish’ SSL/TLS cert lifespan cuts
- Reference: 1729021508
- News link: https://www.theregister.co.uk/2024/10/15/apples_security_cert_lifespan/
- Source link:
As one of the [1]hundreds that took to Reddit to lament the proposal [2]said : "This will suck. My least favorite vendor manages something like 10 websites for us, and we have to provide the certs manually every time. Between live and test this is gonna suck."
The Apple proposal, a [3]draft ballot measure that will likely go up for a vote among Certification Authority Browser Forum (CA/B Forum) members in the upcoming months, was unveiled by the iThings maker during the Forum's fall meeting.
[4]
If approved, it will affect all Safari certificates, which follows a similar [5]push by Google , that plans to reduce the max-validity period on Chrome for these digital trust files down to 90 days.
[6]
[7]
Max lifespans of certs have been gradually decreasing over the years in an ongoing effort to boost internet security. Prior to 2011, they could last up to about eight years. As of 2020, it's [8]about 13 months .
Apple's proposal would shorten the max certificate lifespan to 200 days after September 2025, then down to 100 days a year later and 45 days after April 2027. The ballot measure also reduces domain control validation (DCV), phasing that down to 10 days after September 2027.
[9]
And while it's generally agreed that shorter lifespans improve internet security overall — longer certificate terms mean criminals have more time to exploit vulnerabilities and old website certificates — the burden of managing these expired certs will fall squarely on the shoulders of systems administrators.
[10]Apple drops a bomb on long-life HTTPS certificates: Safari to snub new security certs valid for more than 13 months
[11]DigiCert gives unlucky folks 24 hours to replace doomed certificates after code blunder
[12]Firefox's Mozilla follows Google in losing trust in Entrust's TLS certificates
[13]Entrust faces years of groveling to regain browsers' trust, say rival chiefs
Over the past couple of days, these unsung heroes who keep the internet up and running flocked to Reddit to bemoan their soon-to-be increasing workload. As one noted, while the proposal "may not pass the CABF ballot, but then Google or Apple will just make it policy anyway…"
Even certificate provider Sectigo, which sponsored the Apple proposal, [14]admitted that the shortened lifespans "will no doubt prove a headache for busy IT security teams, juggling with lots of certificates expiring at different times."
The solution, according to Sectigo's Chief Experience Officer Tim Callan, is to automate certificate management — unsurprising considering the firm sells software that does just this. "Automated certificate lifecycle management is going to be the norm for businesses moving forward," Callan told The Register .
However, as another sysadmin pointed out, automation isn't always the answer. "I've got network appliances that require SSL certs and can't be automated," they wrote. "Some of them work with systems that only support public CAs."
[15]
Another added: "This is somewhat nightmarish. I have about 20 appliance like services that have no support for automation. Almost everything in my environment is automated to the extent that is practical. SSL renewal is the lone achilles heel that I have to deal with once every 365 days."
Until next year, anyway. ®
Get our [16]Tech Resources
[1] https://www.reddit.com/r/sysadmin/comments/1g3dm82/ssl_certificate_lifetimes_are_going_down_dates/
[2] https://www.reddit.com/user/spamster545/
[3] https://github.com/cabforum/servercert/pull/553/commits/76ca560955babfc4ee5dd32f91bf02180cf5a97c
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Zw7mBO8-7pcEO11KTVUEHgAAAIU&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[5] https://www.chromium.org/Home/chromium-security/root-ca-policy/moving-forward-together/
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Zw7mBO8-7pcEO11KTVUEHgAAAIU&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Zw7mBO8-7pcEO11KTVUEHgAAAIU&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[8] https://www.theregister.com/2020/02/20/apple_shorter_cert_lifetime/
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Zw7mBO8-7pcEO11KTVUEHgAAAIU&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[10] https://www.theregister.com/2020/02/20/apple_shorter_cert_lifetime/
[11] https://www.theregister.com/2024/07/31/digicert_certificates_revoked/
[12] https://www.theregister.com/2024/08/01/mozilla_entrust/
[13] https://www.theregister.com/2024/08/08/entrust_faces_years_of_groveling/
[14] https://www.sectigo.com/resource-library/apple-now-joins-google-in-push-to-shorten-digital-certificate-lifespans
[15] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Zw7mBO8-7pcEO11KTVUEHgAAAIU&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[16] https://whitepapers.theregister.com/
You can use a CNAME and another DNS domain, just for ACME.
You don't have to give admin rights. Implement RFC 2136
sounds terrible
But more to the point, I'd be surprised if it improves security much, being that it's been touted for over a decade the average intrusion is something like 6 months or more before being detected.
from 2022
https://www.cybersecurityintelligence.com/blog/how-long-does-it-take-before-an-attack-is-detected-6602.html
"In fact, the average breach lifecycle takes 287 days, with organisations taking 212 days to initially detect a breach and 75 days to contain it. "
Gives the attacker plenty of time to just get the new certs as they are issued if they are expiring every 45 days..
I assume this expiry time doesn't impact self signed(internal CA) certs, I recall that was the case for the earlier reductions in intervals, and my internal certs I set to expire after about 800 days and have yet to have any browsers complain in the past 5-6 years.
Wait. What?
Max lifespans of certs have been gradually decreasing over the years in an ongoing effort to boost internet security.
So, it's useless.
More work, offloaded to the end users, for less effectiveness?
Enshitification intensifies.
Re: Wait. What?
>So, it's useless.
So far, but once the lifespan is negative we predict an inflection point in security
The solution...
The solution is to use a non-advertising-supported browser that doesn't enforce use of HTTPS.
Of course, I don't have any control of what my clients use, so my static http website (no login, no cookies, no tracking) is being forced over to HTTPS between now and Christmas.
OK, then let's focus on really strict security
Let's shorten the lifespan of certs to 48 hours, so stolen certs will basically expire immediately.
Or why not 12 hours? 2 certs a day should be worth it to stay secure, right?
Then, why not 5 minutes? Would be much more "secure" than 12 hours.
/s in case this wasn't obvious.
Somewhere along the lines I lost the plot on why shorter lifespans are regarded as more secure.
Sure, shortening 8 years to 3 seemed to make sense. 3 years to 1 year? Already questionalble.
But shorter? What's the actual meaning?
If a cert holder cannot be trusted to not spill their production certs for one single year, why trust them at all, you know, with all the rest of our business?
Re: OK, then let's focus on really strict security
Then, why not 5 minutes? Would be much more "secure" than 12 hours.
how about a new cert per connection?
looks like an excuse for the TLA's to ensure compromised certs are refreshed often, thereby crowding out their competitors.
Re: OK, then let's focus on really strict security
Why so much as 5 minutes, why not every connection. And a public key in a DNS record. I guess it couldn't be because the charlatan CA's (i.e. functionally all of them, in case it needed clarification) couldn't middle man rent money in this approach. It is a detriment to everyone, that it just happens this mess was the mechanism available when (Snowden) suddenly it became fashionable to have a lock in an address bar (but not effect any actual security, on any non-updated CMS on the website, of course).
I'll admit I don't require attention to the whole set of problems SSL was purported to solve. But to paraphrase, at least I'm not paid to not understand a decentralised solution could facilitate encryption between two endpoints.
This unread post continues after I click through the self signed cert warnings with, fire and damnation, for any non-public facing service.
At least these days even the non-LE ones are automatic in the sense I log tickets for someone else to swap. just in time.
Not to mention the difficulties of doing automated rotation for public certs, when your service is not HTTP-based, and runs over a cluster of hosts (do they have one cert each? One for the cluster? How to do challenge/response when the cluster is load-balanced and you don't want to give DNS admin rights to the whole network ...)