Apple wants to limit website certificate validity to just 45 days. Cupertino’s iPeople propose to change Safari to reject SSL/TLS/HTTPS sites whose certificates expire “too far” into the future. Is it April 1 already?
First Google wants the cert lifespan to be 90 days, now this? In today’s SB Blogwatch, we wonder why they don’t go the whole hog and drop it to an hour.
Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: Bunny boing.
What’s the craic? Jessica Lyons reports: Apple’s ‘nightmarish’ SSL/TLS cert lifespan cuts
“Headache for busy IT security teams”
Apple wants to shorten SSL/TLS security certificates’ lifespans, down from 398 days now to just 45 days by 2027. … The Apple proposal [is] a draft ballot measure that will likely go up for a vote among Certification Authority Browser Forum (CA/B Forum) members in the upcoming months.
…
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. … 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.
…
Shorter lifespans improve internet security overall [but] the burden of managing these expired certs will fall squarely on the shoulders of systems administrators.
Those poor, overworked sysadmins. Where la Lyons goes, so must Nick Farrell: Apple makes systems administrators furious
“Apple will, of course, bleat”
The fruity cargo cult … made systems administrators unfortunate enough to work on its software furious with a cunning plan to drastically cut the lifespan of SSL/TLS security certificates. … If approved, it will affect all Safari certificates.
…
However, systems administrators will be heavily responsible for managing these more frequent renewals. … The simple answer would be for system administrators to shift their companies off Safari and onto something that does not require updating so often. Apple will, of course, bleat that it is not so secure, but then we are talking about Safari.
Horse’s mouth? Apple’s collaborator, Sectigo, has this to say: Draft Ballot to Shorten Certificate Lifespan
“There’s logic behind this”
On October 9, during the second day of the fall CA/Browser Forum Face-to-Face meeting, Apple revealed that it had published a draft ballot … to incrementally phase maximum term for public SSL/TLS certificates down to 45 days between now and 2027. The draft also phases down the DCV reuse period over time, until it reaches 10 days in 2027.
…
This move from Apple follows Google’s … intention to reduce the maximum validity … from 398 days to 90 days, in a future policy update or a CA/B Forum ballot proposal. … It’s important to note that it is just in the proposal for discussion stage, but it clearly sends a strong message to the industry.
…
But although there’s logic behind this, the gradual decrease in certificate lifespans will no doubt prove a headache for busy IT security teams juggling with lots of certificates expiring at different times. … Companies that use manual methods for tracking and monitoring certificate[s] will soon find themselves overwhelmed.
But is it really more secure? Yes, according to bawolff, who explains why:
The main issue is lack of a working revocation mechanism. … We don’t have a really good way of revoking keys after something bad happens. We have some bad ways, but they kind of suck.
Certificate revocation sucks? How so? Mike Pellatt counts the ways:
OCSP is being deprecated, thanks to well-documented privacy issues.
CRL lists are hard to trust and potentially a major performance hit.
Reducing cert lifespan is, probably, the only mitigation possible for what is, at its core, a broken infrastructure.
Seems like a good idea then? Not so fast; reg worries the cure might be “worse than the disease:”
I’ve seen this sort of thing over and over again as protocols are removed from browsers … with the result being that people have to use old versions to manage … old stuff that is no longer being supported. This forces you to use an old browser that will likely get hacked if you forget and open a modern site. … I had this with UPSs, printers, data acquisition systems, lab testing equipment, etc.
[And it] will result in more expired certs, meaning more people will be trained to ignore expired certs. … Even if the updates are automated, the real risk is that the signing cert is hacked, and that will just keep getting used in automation. The thing that needs quicker response time is invalidation. The same logic led to decades of 30-day password expiry.
And u/fsweetser agrees:
I’ve worked with a good number of devices where you literally can’t update the cert [except] via interactive web login, period. … This is going to be a pain point that will likely lead to, “Yeah, just ignore the cert errors.”
Any other unintended consequences? This Anonymous Coward dreams up a doozy:
The problem [is] as the expiry horizon shortens, the need to automate the replacement increases. And that mass automation will provide an avenue for an attack itself — especially for 5-eyes agencies.
Meanwhile, erichocean sounds slightly sarcastic:
Remember: The most secure device is a device that doesn’t work at all. Thank you SSL/TLS cert lifespan cuts for making this a reality. Well done, everyone.
Starts off hard; finishes awwwww
You have been reading SB Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites—so you don’t have to. Hate mail may be directed to @RiCHi, @richij, @[email protected], @richi.bsky.social or [email protected]. Ask your doctor before reading. Your mileage may vary. Past performance is no guarantee of future results. Do not stare into laser with remaining eye. E&OE. 30.
Image sauce: Brooke Lark (via Unsplash; leveled and cropped)
Recent Articles By Author