Sysadmins rage over Apple’s ‘nightmarish’ SSL/TLS cert lifespan cuts -- "Maximum validity down from 398 days to 45 by 2027"
Posted by throwaway16830261@reddit | linuxadmin | View on Reddit | 168 comments
elvisap@reddit
This is doing a fantastic job of exposing what my friends and colleagues refer to as "shitmins". Folks who can't automate, can't scale, and insist on every sysadmin style task being 1990s style right-clicking.
I'm all for it. Burn garbage IT to the ground.
Surph_Ninja@reddit
It’s not even hard. Both Linux and Windows auto cert renewal is a 5 minute setup. I have no clue why anyone is still doing this manually.
oxwilder@reddit
A certificate that shows we trust you, but not much
Amidatelion@reddit
This isn't going to go over very well with a lot of industries stuck in the past.
Like, all of the US's energy infrastructure.
Trying to convince customers to let us do LE on their FQDNs is a fucking nightmare.
Qel_Hoth@reddit
Well, you can either rest assured or be terrified, your pick. Lots of the energy infrastructure won't be impacted by this because even if it does support TLS, it probably isn't configured.
grepe@reddit
🤦♂️
HoustonBOFH@reddit
And when this gets too difficult, a lot more will turn off SSL.
Amidatelion@reddit
Oh believe me, I know. Nothing short of the Big One of domestic terrorism incidents is going to move these dinosaurs. In the mean time, I document all my suggestions and protests and hope I don't get subpoenaed.
CatoDomine@reddit
All CAs support ACME. You don't have to use let's encrypt.
djamp42@reddit
All end devices don't.
CatoDomine@reddit
Okay ... Let's try to decipher this incredibly vague comment.
I'll start by attempting to define the term "end devices". Let's assume you mean "hosts that will terminate a TLS connection".
"All" here is a little tricky, because I don't think you mean to say that "All devices that will terminate a TLS connection do not support ACME" because that is clearly not true. So I guess you mean to say "not all devices that terminate TLS are capable of requesting a cert using ACME".
That is a true and accurate statement! However, devices here very likely is meant to refer to something that runs a proprietary or locked-down OS which does not permit the user/admin to install an ACME client.
Devices that fit this description are usually devices that require a cert for their admin interface, an interface you don't want the general public to access. That being the case, a cert issued by a private CA should be sufficient. Private CAs will still be able to issue trusted certs for several years. When an admin installs a Private CA trusted root in their browser, leaf certs will not be limited to 90/45 days as proposed by the CA/B.
TL;DR: use Private CA certs for your infrastructure appliances. Some Public CAs will even run your private CA for you on their infrastructure.
djamp42@reddit
Exactly, however I would never assume every single org in the entire world is doing it like this.
At the end of the day I have an ACME client in everything that takes a certificate, I want ACME on a private CA but haven't looked into that yet
Kaelin@reddit
Microsoft internal CA doesn’t
CatoDomine@reddit
Microsoft has no excuse. They are a CA/B member.
LaxVolt@reddit
The only possible issue is browser enforcement. Didn’t Google say they were going to start flagging sites with certificates with too long a validity?
ibanez450@reddit
They do have this, but I believe it can be modified via GPO for exactly this scenario.
NotAskary@reddit
Already had problems with this, had to use Firefox for a lot of work because Google doesn't like dev keywords.
X-Istence@reddit
For publicly rooted CAs. Where I work we still have internal CAs spitting out 10 year validity certs and using sha1, no issues on any browsers.
LaxVolt@reddit
That’s good to know
racomaizer@reddit
Of course they have an excuse... pay up.
autotom@reddit
Hashicorp shares 📈
the_cocytus@reddit
I think you mean IBM
m3adow1@reddit
If you think the companies having problems with this change are using IaC tools, you're much more hopeful in professional life than I am.
Potato-9@reddit
I upvoted you but their shares won't go up because existing customers are happy. It'll drive more IAC.
fractalife@reddit
For a split second I thought I was in a sub for an entirely different industry lol. Then I realized the acronym made 0 sense in that one haha.
techleopard@reddit
I imagine it'll give a nice foothold for any IT team that is looking for a way to tell management "no" on buying and supporting a bunch of iPhones.
Pyro919@reddit
LE?
ultratensai@reddit
Let’s Encrypt
Pyro919@reddit
Gotcha, there's a lot of ways to rotate certificates besides lets encrypt.
TheDumper44@reddit
Not really. Fucking get good or die.
Amidatelion@reddit
While I sympathize with the spirit behind this, Apple isn't going to be the one to make these dinosaurs budge.
That will probably only happen with a domestic terrorism incident.
TheDumper44@reddit
Apple and Microsoft have forced the industry to get better with certificates. This is just one of many steps they are changing which is good.
If a company can't comply with new safety regulations they should be fined, just like with OSHA. Long lived certificates are a bad thing.
Amidatelion@reddit
Wholly agree on the regulations. But I could run nmap against every single one of our customers public and private infrastructure, and find TLS 1.1 still in use probably among 15-20% of them to some degree. Apple and Microsoft successfully pushing this in forums and in their own ecosystems only does so much. It needs to be sticking points in compliance frameworks like PCI standards and these need to be more aggressively audited.
But more likely is a bad actor takes out huge chunks of the east or west coast's power.
TheDumper44@reddit
TLS 1.1 is not seen that much except on legacy systems now a days. I am sure you could find it but the system is either super locked down via other methods and internal where I have seen no password services for everything imaginable. Just having encryption period is a win sometimes.
With those you might as well get them into a good cert rotation posture and start thinking about it. There is a surprising amount of applications that actually do not reload certificates and need a full restart (logstash at least the versions I used), and some that need a refresh or reload to load them (elasticsearch needs a REST call).
In general though people should be messing with those systems imo and thinking about how to implement TLS is normally a step in the right direction. I have seen it go too far though as well especially with mTLS. Sorry but you don't need encyrption if you are going to a system in the same network that is firewalled or literally on the same box sending encyrpted streams back and forth to local pods.
Basically people need to get off their asses and start implementing real secutiy controls and actually READ the NIST and STIG's. I know reading is hard for 90% of sys ads, but its not that dry and gives good insight AND you can point to the NIST/STIG if something goes wrong basically passing the blame and also looking good as long as it doesn't kill a datacenter (been there).
randomatic@reddit
Tbf, they are stuck in the past, but I think that’s the wrong viewpoint. Apple and google tend to view everyone as a saas, but there are huge industries where that isn’t appropriate.
Suspiciously , this push means Apple/google get a list of active services much more often through the crt process.
spawnvol@reddit
Use Venafi! That’s what we use and we love it.
ScaredyCatUK@reddit
Fix the problems with the revokation proces rather than pretending they don't exist. 45 days is still too long if it's bogus and it's not the solution.
The bigger problem is that even if it's not agreed to, Apple and Google will force it in their browsers - which is why that duopoly need to be broken.
TwoBigPrimes@reddit
Can you say more about the problems with revocation?
pinkycatcher@reddit
Okay, I get that yes everyone should automate, but what's the actual reason behind these cuts?
pleachchapel@reddit
Can a smart person tell me the easiest way to deal with this if it becomes reality?
Coffee_Ops@reddit
Stop manually cutting certs.
Develop a pipeline for automatic cert issuance in prod.
ultimattt@reddit
Hello Acme my new friend, I’ve come to your for a cert again
I’ve issued a request using let’s encrypt, using the http challenge, your response made me want to quit
And the issue that I was trying to solve Has got me fully involved
Within the sound… of crypto
Longjumping_Gap_9325@reddit
Let's Encrypt doesn't scale though (and HTTP challenge is considered weak and doesn't cover alt names in one go), and Org Validated domain level certs (like Sectigo) are going to be a pain if the DCVs drop too, and there isn't really an "ACME for DCVs" (although I've started working up something for our internal org use).
franktheworm@reddit
There are non http validation methods for LE, one of which is DNS based... https://letsencrypt.org/docs/challenge-types/
isbeardy@reddit
That are kinda hard to automate properly because a lot of providers have either not enough granularity in their token permissions (giving service full control of your domains is kinda scary), have limits on their api usage (so you cannot be sure that your request has passed), or apis are just poorly implemented and sometimes lose updates or require you to fully rewrite zone on update.
BloodyIron@reddit
No they're not. Use providers that are actually modern. Hell, even ZoneEdit has the capabilities for it.
throwawayPzaFm@reddit
Yeah you go tell Hans the paranoid retired doctor running an online store on a platform that he needs to give the keys to the kingdom to his it guy.
BloodyIron@reddit
I'll gladly take your client thanks. Who exactly should I engage for the initial discussion? I mean... if you're not willing to do your job properly, I'll gladly do it for you.
throwawayPzaFm@reddit
You're a walking, writing, Dunning-Kruger proof.
420GB@reddit
Who is running that online store if not their IT guy? If it's fully managed SaaS then the hoster takes care of the cert. If it's self-managed or self-hosted in some capacity then the same person who runs the whole system anyway can and will also run (its) DNS.
throwawayPzaFm@reddit
We have a hybrid system where the platforms are SaaS but the client retains control of DNS. And a lot of clients to migrate.
carsncode@reddit
Must be nice getting to choose the vendors for all your services with no interference, approval processes, or oversight!
BloodyIron@reddit
Of course I have to deal with that, they're called clients. And clearly I seem to make a more convincing case of my recommendations than you do.
Ever had to deal with NERC-CIP before? PCI compliance? NIST Security Frameworks?
I have, it's been my job many times over. Dealing with auditors, making technical recommendations, architecting solutions, and executing them.
And yet Let's Encrypt fits into that because it meets or exceeds typical needs of such systems.
So... you were saying something about accountability?
AndreasTheDead@reddit
have fun to get your Enterprise to give you apikeys for the public dns to do dns validation
franktheworm@reddit
Either this is a big enough problem to warrant taking a proper modern approach to, or people are crying over nothing.
As always, if the put of the box solution is too wide open for your liking, you step up and be the engineer you're being paid to be and build a layer in front of it to provide the required guard rails, or you start moving to another solution that better fits your needs, or if you're in the cloud you use the providers cert manager....
There is always a way around the problem, and at its core it's what professional Linux Admins / DevOps Engineers / SREs / Platform Engineers / etc are paid to do - find solutions to problems.
carsncode@reddit
Yes, it's what we're paid to do, and we're all already busy doing it, which is why the community tends to react negatively when companies like Apple and Google stroll through and throw another problem into the pile.
AndreasTheDead@reddit
Yep, exactly that, im shure companys will find solutions, im not shure if the admins have time to work on an additional not needed problem.
Coffee_Ops@reddit
You only need api keys for the subdomain you're targetting.
*.service.domain.tldcerts can use a scoped api key forservice.domain.tld.You were already terminating HTTPS on the device doing validation, yes? And anyone controlling that endpoint can already see all the traffic, yes?
KittensInc@reddit
ACME can handle org validation just fine. The protocol allows you to specify an external account binding, which can be used to link an ACME installation to a corporate account. There is also support for external challenges via pre-authorization.
In other words, most of the paperwork can remain exactly the same. It's just the actual issuing and renewal of the cert itself which is getting automated.
Longjumping_Gap_9325@reddit
Sectigo uses the MAC key and the external account binding, but what I mean is right now you have to do the DCV yearly for the top level domains you may have, and and that's the part I'm meaning can be a sticking point in larger orgs depending on your infra setup and organizational setup. It may require some reworking at the "people/departments" levels too
ultimattt@reddit
Sorry, was making a joke to the “sound of silence”
Longjumping_Gap_9325@reddit
I was really trying to reply to another comment and failed lol
I did get your reference, been a longgg day of fire fighting like normal.
Apologies for what I'm sure seemed like a snarky or get off my lawn type reply!
ultimattt@reddit
All good. Now get off MY LAWN!
TriforceTeching@reddit
As a network engineer I have a ton of stuff that can't do automatic issuance. This is going to be a pain.
HoustonBOFH@reddit
As a network engineer, I have a very old Ubuntu VM just to log into old Java based switches and firewalls.
Coffee_Ops@reddit
You probably have a lot of things that can do automatic issuance, and support cron jobs to scp those certs where they need to go.
traversecity@reddit
It is the various network devices, no means to automate. Though something could be hacked together with expect, or I suppose Python scripting.
I’ve worked a couple of global hospitality systems, all of the business systems and vpn endpoints were manually provisioned. Betcha the same gizmos from twenty years back are still in use.
Coffee_Ops@reddit
If they support SSH, you have means to automate.
Ansible, Posh-SSH, python, even just janky crontabbed bash scripts may be sufficient.
faajzor@reddit
Why the downvotes wtf
automation is the only way to be successful. It's 2024 everyone, forget your pet devices you manually update.
anotherkeebler@reddit
Check the Ansible commons too
traversecity@reddit
I didn’t think of Ansible, it should get the job done.
We use it for a lot of provisioning and maintenance, should have been a first thought.
nikdahl@reddit
I have some SAP clients that have no explicit chain trust, so we have to supply them with the public cert before applying it to production. We had a 90 day timeline for this all to take place.
Well, I hope they get their shit together. Because I hate supporting their dumbasses too.
Tacticus@reddit
... there's your problem
though again internal certs aren't covered
lebean@reddit
The hole there is for internal services with no outside exposure, so no http validation possible, but also with DNS that isn't managed via API, so no DNS validation possible.
I guess having your own internal CA is the only real way forward there, but it'd be nice if such things were "acme-able" somehow.
knobbysideup@reddit
It is possible to do dns validation without an API. Once the cnames are in place, you are then good to go. This is how I'm dealing with private certs.
https://www.digitalocean.com/community/tutorials/how-to-acquire-a-let-s-encrypt-certificate-using-dns-validation-with-acme-dns-certbot-on-ubuntu-18-04
Coffee_Ops@reddit
There are internal CAs that support acme.
If you have no outside exposure your options are internal, DNS validation +scp schlepping cers, or just front it with a load balancer that can do acme.
FunIllustrious@reddit
step-ca supports ACME. I started putting one togeter at home to play with, but work happened and I haven't finished setting it up.
Coffee_Ops@reddit
I thought only the paid version supports acme, not the community edition.
Tacticus@reddit
in addition to step-ca stuff like vault has a PKI engine that can generate certs. aws private Ca could do it. if it doesn't have a half decent library for automatic cert generation\rotation it deserves to go into the trash heap by this point.
BloodyIron@reddit
in all environments... because all environments that are not prod should be proper replications of prod so you can accurately test issues in non-prod before they reach prod.
Coffee_Ops@reddit
Baby steps-- you don't want to scare off those who are dipping their toes into the devops world.
BloodyIron@reddit
This isn't just a DevOps thing.
binkbankb0nk@reddit
And, arguably replace software systems that don’t support it in time. It’s an expensive endeavor but it’s not really an option if this goes through.
If a manual process with a vendor is required, that vendor will have to fix it on their side so it’s automated. Apple and Google can effectively force companies to stop doing manual validation like so many relied on. The business process will have to separate from the technical process.
HoustonBOFH@reddit
Turn off SSL. Dead simple, and works. And a lot of people will do it. And we can go back 10 years to "How do we get more people on SSL?"
fab_space@reddit
Pipeline vis github runner is ok. Tested and working like a charm. U can deploy securely to remote vault by using tons of solutions out there, i like tailscale and infisical for the flawlessy integration.
theblindness@reddit
Same as always. Automated DNS challenge for ACME scripts, wildcard certs, reverse proxies, ansible, internal PKI with MDM. Many workflows based around LetsEncrypt and other ACME solutions already rotate certs every month, except that it will be more crucial to make sure that the monthly automation work and the grace period drops from 2x the monthly cycle to 0.5x. It's a dare from Apple to automate all the things. Maybe you can use this to justify finally getting rid of all manual certificate processes and be done with them once and for all.
ShaneC80@reddit
I don't claim to know much about this stuff, but my homelab (re: a couple of Pis running docker compose containers) was easy enough for me to automate my SSL certs once I got past the initial "validate via DNS instead of HTTP".
I haven't had to manually touch the certs in a couple years. Aside from from perhaps adjusting the interval of the updates, how is this a "problem"?
theblindness@reddit
Why are you quoting "problem" in your reply to me? I'm pretty sure I didn't say "problem". I only listed automation tools and strategies. If you want to know why certs are a chore, check the other comments in the thread. Enterprise environments are a lot different from homelabs. It mainly comes down to products where automatic certificate rotation via ACME protocol is not possible.
ShaneC80@reddit
I used it in quotes as I wasn't seeing how the problem was a problem. Meaning not realizing the impact. I assumed (...and shouldn't have...) that automating renewals was more prevalent overall.
arwinda@reddit
Don't forget to monitor the remaining lifetime of certificates. Easy way to detect if the pipeline is broken.
eclipseofthebutt@reddit
ACME if you can, SCEP or NDES if you can't.
Ryluv2surf@reddit
i just have a cronjob for certbot. Should be fine?
capricorn800@reddit
u/Ryluv2surf what does it do?
0bel1sk@reddit
it just auto rotates certs. been around for years and is pretty bulletproof
capricorn800@reddit
u/0bel1sk I have a common wild card certificate that I have to install on 15 test servers every year.
How I can automate the process?
0bel1sk@reddit
cron certbot, rsync certs, sighup server if changed check here for some instructions: https://certbot.eff.org/
AmusingVegetable@reddit
Automation.
Strange-Initiative63@reddit
Get with the last decade and automate your certs.
Krytos@reddit
Win-acme.com
Or certbot for Linux
TheDumper44@reddit
Do nothing because the industry has already figured this out it's just a matter of implementation.
CatoDomine@reddit
All CAs, should support ACME at this point. I don't think the CA/B forum would trust their root if they didn't.
BirdLawyer1984@reddit
Block Apple devices.
NeoMatrixJR@reddit
Therapy and caffeine....
AbortedFajitas@reddit
Certbot and let's encrypt are terrible solutions for production workloads.
BloodyIron@reddit
Let's Encrypt is used in production workloads globally and has been for years. You're out of touch gramps.
AbortedFajitas@reddit
What services uses LE in production? The local pizza shop down the street?
toikpi@reddit
Here's a couple more for you
BloodyIron@reddit
You've clearly done ZERO homework here bud. Stop talking out your rectum.
deacon91@reddit
https://www.nsa.gov/
https://letsencrypt.org/stats/
https://ct.cloudflare.com/
These are just websites that uses LE. We also use LE + cert-manager for our production container workloads and we certainly aren't alone in that.
Tacticus@reddit
Certbot was never really anything more than an example\small scale solution. there are far better systems for managing certs on "production" workloads now.
yeeeeeeeeeeeeah@reddit
if you can't figure out automatic cert renewal, find a different field to work in. Maybe plumbing or electrical if you prefer manual labor.
8XtmTP3e@reddit
Have you worked in business? All those firewall and other security appliances that you have no control over, you have no chance. I worked with such a company for 7 years, and tried to get this stuff automated, but because it didn’t save us money, it didn’t make us money, no one was interested and it never got roadmapped.
yeeeeeeeeeeeeah@reddit
I've never worked in an environment where I did not have at least SSH access to firewalls, switches, etc. if you don't have administrative access to those devices, point to the vendor who supports them. If there is no vendor and the burden is still falling on your lap, find the exit and leave.
8XtmTP3e@reddit
Right, but SSH access is only half the story. Do you have easy access to install whatever binaries/libraries you want? Will they work on whatever "hardened" (aka "outdated") operating system your vendor is shipping? Will this remove the ability to get support from the vendor, so will your company policy allow you to do whatever?
From my point of view, if you did anything and it wasn't directly causing a support case then I wouldn't have cared because I wanted it to be automated. But I was tier 4 support, last line of escalations. The three guys and girls before me, some portion of their job was dedicated to finding reasons that we didn't have to support you because you had modified your appliance in an unsupported way and we would probably try to upsell you on premium case-by-case support because we're a business who needs to make money without sinking our time and salaries into supporting something that the customer has futzed with in unknown ways.
yeeeeeeeeeeeeah@reddit
Not having root access to every device under your roof is an organizational failure. If somebody at a higher pay grade onboarded gatekeeping vendors who are actively preventing the implementation of new standards, you ditch them.
compu85@reddit
Clearly, this is someone who hasn't worked with medial software, or industrial automation. If you think you can just "ditch" the junky software that makes 1/3 or more of your company's revenue I bet the COO would love to have a lill discussion first.
yeeeeeeeeeeeeah@reddit
I have worked with medical software and spent a regrettably large portion of my career dealing with garbage EHR software.
It turns out, there are a lot of different EHR vendors who all sell the same shit. It's all just a database wrapped in a front-end interface. You pay the vendor mostly so that they add more hard-coded esoteric diagnostic and billing codes. Any competent vendor can pull you out of a bad situation with a less-than-stellar vendor, if you're willing to put-up with the up-front transition cost. Problem is, doctors are some of the stingiest bastards in the industry and if it were up to them we would all be running SMBv1 and HTTP with no encryption because "it works".
You're not required to accept the technical debt of your employer. If they refuse to change, you can leave and they'll be forced to pay somebody else more money to get less done until their house of cards collapses.
arwinda@reddit
Your control over this is the purchase order.
yeeeeeeeeeeeeah@reddit
preach
arwinda@reddit
No, don't sign. Stop preaching, the vendors won't hear that, they only care about 💰
autotom@reddit
If you haven’t got this automated by 2027 I have no sympathy for you. It’s not that difficult.
hmoff@reddit
It's a lot easier to automate once than remember the manual procedure every year
stormcloud-9@reddit
I think forcing this opinion on everyone is a stupid decision. If it's not a burden for you to replace certs at a frequent interval, then great, you can request certs with a short life span. Absolutly nothing stops you from doing so. Why should others be forced to do so?
Even if the cert is compromised, you're pretty limited in what you can do with it. Things like PFS prevent any sort of traffic sniffing. You have to actually use the cert to terminate SSL. So you'd have to either hijack DNS or somehow insert yourself as MITM, neither of which are trivial (yes, if you run a coffee shop, you could do it, but hardly worth the effort for such limited gain). And if you're running a high-profile web site (e.g. a bank), where even a single compromised user would be catastrophic, then yes, you should absolutely be using a cert with a short life span.
So I'm not saying there's no advantage to a shorter life span. I'm just saying not everyone is a bank.
KittensInc@reddit
It's not about you, it's about the ecosystem.
Time and time again CAs have refused to revoke wrongly-issued certificates in a timely manner because they believed it "does not form a security risk", their incident is "not serious", revocation would require "significant resources" and impact "thousands of large enterprises" in "critical sectors". In other words, they refuse to follow the rules set by the root stores because they... don't feel like it?
Most of the times the certificates had to be replaced due to a technicality and there would indeed not be a major breach. But that doesn't matter: the rules say they have to replace the certificates. If they can't follow the rules in this case, why should they be trusted to follow the rules when there is a safety-critical incident? And if they can't be trusted, why should they even be in the CA root stores?
The entire goal of reducing certificate lifetimes it to force everyone to create an automated and streamlined certificate workflow. When there is a serious incident in the future (say, a CA's private key being leaked) everyone can quickly reissue their certs, so the originals can be rapidly revoked. It means we don't have to sit around with a completely broken internet ecosystem while BigCorp is spending three months having interdisciplinary stakeholder meetings trying to figure out how to rotate their certs.
lemaymayguy@reddit
Reminds me of the windows11 and tpm thing
pastelfemby@reddit
Not sure why you were being downvoted when you were speaking facts
Some places insistent on doing things 'the way its always been done' might not like the change, but its a very valid one
weeboards@reddit
time to fire up caddy and go to bed :)
ancientweasel@reddit
A lot of stuff will just stop working on Apple products then.
HoustonBOFH@reddit
I am thinking of forcing 90 day expires on my stuff just to cause problems.
kevdogger@reddit
Don't know what's wrong with 90 day limit
yeeeeeeeeeeeeah@reddit
Nothing. There is nothing wrong with a 90-day limit. This thread is full of crybabies who either don't understand how to automatically renew certs or who are being with gatekeeping vendors, in which case it isn't their problem.
kevdogger@reddit
But I think 45 day is really ridiculous
yeeeeeeeeeeeeah@reddit
... maybe change the configuration of your auto-renewal cron jobs to update the cert every \~30 days instead of every \~60...? This is like 2 minutes worth of work, max. You have automatic cert renewal, right?
kevdogger@reddit
Yea..a lot through either traefik or acme.sh. I just run a dumb home lab however
xylopyrography@reddit
It's way too short for control systems for one.
MardiFoufs@reddit
What do you mean too short? To me, long lived certs just lead to having no process for updating the certs at all, which then leads to even worse problems-just way down the line. Either you have an infra for updating your certs, or you don't. And I mean, control systems should have self signed certs anyways, which are exempt. If they don't, and have long lived certs it's again very likely that you're in a world of pain anyways.
The goal is to not encourage devices dying after a few years because someone thought that the next guy will deal with the certs.
DogThatGoesBook@reddit
I do think they’ve forgotten that SSL certs are used to encrypt a variety of protocols (email, LDAP, XMPP etc) and these might be less trivial to update and automate than web certs. That and the number of appliances which don’t support any automation. The naive/idealistic me thinks this could encourage them to include ACME support in their products
schorsch3000@reddit
maybe i'n naive too here, but how is the protocol in use less trivial to change the certificate?
Issn't it just putting the file in the right place and restarting the service / tls-offloader?
For appliances, shore, that, at least should convince them to have an api where you can push new certs.
lynsix@reddit
I get people’s problems with this. However I’ve got public facing stuff through CloudFlare, use their 10 year origins since they are the ones that do that validation and they don’t care. Anything local goes through HAProxy that already rotates every 60 so I’d just need to lower that.
For appliances I guess I’d just have to get real friendly with Ansible.
TophatDevilsSon@reddit
No. NO. NONONONONONONOOOOOOOOOOOOOOOOOOOOOO
CammKelly@reddit
Need better, cheap/free and ubiquitious ways to do cert management. Atm, far too many things expect manual intervention.
altodor@reddit
An internal CA does this. It's not pretty but it's the answer.
CammKelly@reddit
Better and ubiquitious were key words in what I said above, and that arguably is more to do with the device providing ease to interact with it to do cert management rather than the CA itself.
altodor@reddit
There's too much old crap out there that will never support ACME because the vendor got sold and bought several times and nobody knows how it works anymore (VMware), or the product was end of life 20 years ago (printers). I was addressing the "stuff that expects manual intervention" part.
0bel1sk@reddit
so like…. certbot?
asynchronous-@reddit
CertBot installs just went through the roof
MekanicalPirate@reddit
No
glotzerhotze@reddit
If this is a nightmare for you, you already work in a nightmare. Be grateful someone woke you up!
Jwblant@reddit
Do this say that DV certs like LE will have a validity of 10 days? Or did I read that wrong?
Shmoe@reddit
You guys see they exempted self signed certs from this, right?
CoderDevo@reddit
ok. So your test and non-browser use cases are good.
Also private CAs of all kinds are exempted.
AdrianTeri@reddit
Should come down to 7 days & lower solving revoking issues and most preferably be issu-able via DNS records.
The industry's ~1600 vendors with exception of LetsEncrypt that's altruistic is NOT a "nightmarish" situation for security?
arwinda@reddit
It is not. At least not as long as there is no known security issue. Once there is an issue, everyone and their dog are scrambling to get updates and new certs in place, trying to remember all the manual steps necessary to renew and install the cert.
I wonder how many companies which need very long cert validaty times have a plan in place for rotating the cert in case of an emergency. Probably not that many.
AdrianTeri@reddit
NOT a grave concern when any of these ~1,600 can issue a valid certificate for your domain?
Tacticus@reddit
just look at the companies that needed 9 + months to rotate dev certificates from the recent CA nonsense
pottaargh@reddit
If only there was a place where you could say “Let’s encrypt!” and get short-lived certificates for free. And some way to automate it… A “cert manager” or even a “certbot”, if you will. We can dream…
RocketsledCanada@reddit
Let’s Encrypt
BloodyIron@reddit
Good.
Intergalactic_Ass@reddit
Google: "Every day someone visits your website our Certificate Authority will call your CEO and ask them if they know this person and whether they're a cool dude."
This is internet security.
(Also we'll give the keys to the NSA lol fku)
AxisNL@reddit
Fun for services like Shoutcast/Icecast that rely on a single tcp stream being up for a looooong time ;)
fubes2000@reddit
The certificate should only ever be used at the start of TLS session negotiation, after that the stream should not give two shifts if the cert invalidates or changes.
AxisNL@reddit
True, but software like Icecast doesn’t support reloading the cert without restarting the whole service, ending all connections. And those pesky antique streaming radios just stop. People have to manually start the stream again. Horrible protocol design 😂
arwinda@reddit
If you want that kind of HA, you already have a proxy in front of it which terminates the cert and deals with this transparently. Otherwise no matter how long the cert is valid, at some point it will break the stream.
Salander27@reddit
Yes, the correct way for this to be implemented is for the server software to support reloading ssl certs without breaking existing connections. Keep existing connections open (I assume they are tcp) and new connections use the new cert. There's plenty of software out there that does this exact thing, it's not rocket science.
fubes2000@reddit
This.
autogyrophilia@reddit
Not how TLS works
Darkk_Knight@reddit
It's not a huge deal as my renewals are automated and I use HAProxy / ACME Certificates on pfsense. Heck, even ProxMox have ACME tools built-in. I've set all my certs to renew every 30 days.
I do worry that Let's Encrypt infrastructure may not able to keep up with frequent cert renewals. So we'll see what happens.
DarrenRainey@reddit
For modern devices that shouldn't be much of an issue. I have lets encrypt with a cron task that runs certbot every few days to keep my SSL cert up to date using ACME DNS records. How its going to be implemented could be a concern since most business still have manual procedures to install certificates (which is more a business protocol issue rather than a techincal one).