Sounds like free money for all those certificate authorities out there. Imma start my own CA with blackjack and hookers.
This’ll never happen. The rest of the computing world will just say “nah, get fucked”
Good, certificates should be automated anyways. Much more reliable than the once yearly outages because nobody renewed the thing or forgot some systems.
Good, certificates should be automated anyways.
The problem being when that can’t be easily automated? Did you read the article?
They should be automated too.
The fact that I can’t use terraform to automatically deploy certs to network appliances is a problem.
Ugh. Righteous ideas about how things should work don’t change the fact that these network appliances doing it the wrong way still have years of time left before the bean counters consider them depreciated and let us replace them. Or that we’re locked into a multi-year contract with this business system that requires updating certs through a web UI.
Yes, there are almost always workarounds and ways to still automate it in the end, but then it’s a matter of effort vs stability vs time savings.
I love automating manual sysadmin actions, it’s my primary role on my team. Still, ignoring the complications that will unavoidably arise in trying automating this for every unique setup is incredibly foolish.
By this logic, we should still be using copper phone lines, analog TV, and 3G should never get switched off. Obviously there are always budget constraints but technological progress does not wait for shitty vendors.
I work mainly in cloud and Kubernetes environments where this stuff is already automated. New vendors are often just deploying new containers into a cluster.
Technically, you shouldn’t even deploy certs to network appliances or servers but they should fetch certificates automatically from a vault. I know there’s minimal support for such things right now, but that should be fixed by vendors.
Even Microsoft supports such solutions in Azure both with PaaS components and Windows and Linux servers (in Azure or onprem) via extensions
True.
cert-manager is an amazing tool for deploying certificates for containerized applications. There’s no standardized way to deploy those certs outside of containers without scripting it yourself though, unfortunately.
Oh yes, let me just contact the manufacturer for this appliance and ask them to update it to support automated certificate renewa–
What’s that? “Device is end of life and will not receive further feature updates?” Okay, let me ask my boss if I can replace i–
What? “Equipment is working fine and there is no room in the budget for a replacement?” Okay, then let me see if I can find a workaround with existing equipme–
Huh? “Requested feature requires updating subscription to include advanced management capabilities?” Oh, fuck off…
Good incentive for the provider to fix it or go out of business.
Smells like Apple knows something but can’t say anything. What reason would they want lifespans cut so short other than they know of an attack vector that means more than 10 days isn’t safe?
AFAIK they’re not a CA that sells certs so this can’t be some money making scheme. And they’ll be very aware how unpopular 10 day lifespans would be to services that suck and require manual download and upload every time you renew.
Smells like you didn’t read the article, it’s an ongoing trend:
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 about 13 months.
Thank you for the smug response however I did indeed read the article and going from 13 months to 10 days is not a trend but a complete rearchitecture of how certificates are managed.
You have no idea how many orgs have to do this manually as their systems won’t enable it to be automated. Following a KBA once a year is fine for most (yet they still forget and websites break for a few days; this literally happened to NVD of all things a few weeks ago).
This change is a 36x increase in effort with no consideration for those who can’t renew and apply certs programmatically / through automation.
I did indeed read the article
Smells like Apple knows something but can’t say anything.
Then do explain your conspiracy theory. Sectigo could go for a money grab, otherwise… probably just forcing automation without thinking of impact, as usual.
This change is a 36x increase in effort with no consideration for those who can’t renew and apply certs programmatically / through automation
Don’t worry. All that old gear is at least 45 days old - so old - and isn’t an apple product anyway probably. Ergo, support isn’t their issue and you will have to take that up with your OEM because la-la-la-laaaaa, can’t hear you. Wanna go ride bikes?
Reducing it to one year made sense, one year down to 10 days is actually a fucking massive difference. Practically speaking, it’s a far, far bigger change than 8 years down to 1.
This isn’t just an “ongoing trend” at this point, it would be a fundamental change to the way that certificates are managed i.e. making it impossible to handle renewals manually for any decently sized business.
I’m sorry, but has no-one heard of https://letsencrypt.org that issues certificates via API for free?
I would not be surprised if certificates at some point will be issued for each session.
I’m sorry, but have you ever needed to manage some certificates for a legacy system or something that isn’t just a simple public facing webserver?
Automation becomes complicated very quickly. And you don’t want to give DNS mutation access to all those systems to renew with DNS-01.
You can delegate to isolated nameservers with DNS-01, there’s no need to have control over the primary zone: https://www.eff.org/deeplinks/2018/02/technical-deep-dive-securing-automation-acme-dns-challenge-validation
Yes, and that is where we enter the complicated territories…
How complicated is it to have a CNAME? /s
Did we read the same article? DNS-01 challenges require updates to DNS. This means you need an API for your DNS. This means you now have to worry about DNS permissions in your application cert workflow. We’ve just massively increased blast radius! Or you could do it manually but that’s already failed.
All of this is straightforward with infrastructure-as-code. While I don’t struggle with that, I’ve watched devs and sysadmins both stare blankly at this kind of thing for days at a time.
If you think it’s just too easy but people are still discussing it, please entertain the notion that you may have oversimplified the situation in your assessment and that as assumptions become clarified you may yet soon understand a horror that apple can’t quite grok.
Ahh yes the: we can’t have self signed certificates for security reasons but also can’t open up the environment to the web, and we dont have our own CA server, trifecta.
Solution: awkward, manual, certificate import process from a 3rd party vendor.
AWS makes this impossible in a few places such as a fair number of ACM use-cases.
I think your cert-per-session idea is interesting. We’d need significant throughput and processing boosts to make that happen, probably at least on the order of 10X computing speeds and 10X transmission speeds across the board minimum. These operations are computationally intense and add data to the wire so, for example, a simple Lemmy server with hundreds of users slows to a crawl and a larger site eg Mastodon goes to dialup speeds or worse. You can test at home by trying to generate an x509 self-signed cert before connecting to a website every time.
Automated certificate lifecycle management is going to be the norm for businesses moving forward.
This seems counter-intuitive to the goal of “improving internet security”. Automation is a double-edged sword. Convenient, sure, but also an attack vector, one where malicious activity is less likely to be noticed, because actual people aren’t involved in tbe process, anymore.
We’ve got ample evidence of this kinda thing with passwords: increasing complexity requirements and lifetime requirements improves security, only up to a point. Push it too far, and it actually ends up DECREASING security, because it encourages bad practices to get around the increased burden of implementation.
spending $300 every 90 days instead of 365 days is so much better /s
i hate apple so much
I was in a meeting before the summer discussing this with Digicert we asked if you would need to pay every 90 days.
They answered that certs will still be bought at 1, 2, or 3 year intervals but can be renewed for free every 90 days.
It’s pretty obvious when you think about it really.
Any post/article with the word “slammed” in it gets a downvote and a no-read from me. That word needs to disappear from journalism/forums/life/etc.
If approved, it will affect all Safari certificates, which follows a similar push by Google, that plans to reduce the max-validity period on Chrome for these digital trust files down to 90 days.
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 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.
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.
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…”
…
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.”
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.
Part of this might be my general disdain towards sysadmins who don’t know the first thing about technology and security, but I can’t help but notice that article is weirdly biased:
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.
Kind of weird to praise random Reddit users who might or might not actually sysadmins that much for not keeping up with the news, or put any kind of importance onto Reddit comments in the first place.
Personally, I’m much more partial to the opinions of actual security researchers and hope this passes. All publicly used services should use automated renewals with short lifespans. If this isn’t possible for internal devices some weird reason, that’s what private CAs are for.
I’m not an “actual security researcher” but I was an “actual security officer” at a reeeeally large shop.
Yes, researchers are right. But they don’t dictate what else we have to let slide to allow time to work this constantly.
And neither are they on the hook for it.
They can be pedants, but they can’t do it blind.
