Sysadmins Rage Over Apple's 'Nightmarish' SSL/TLS Cert Lifespan Cuts (theregister.com) 271
The Register's Jessica Lyons reports: Apple wants to shorten SSL/TLS security certificates' lifespans, down from 398 days now to just 45 days by 2027, and sysadmins have some very strong feelings about this "nightmarish" plan. As one of the hundreds that took to Reddit to lament the proposal 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 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. 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.
... [W]hile 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. [...] Even certificate provider Sectigo, which sponsored the Apple proposal, 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." While automation is often touted as the solution to this problem, sysadmins were quick to point out that some SSL certs can't be automated. "This is somewhat nightmarish," said one sysadmin. "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."
The Apple proposal, 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, was unveiled by the iThings maker during the Forum's fall meeting. 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.
... [W]hile 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. [...] Even certificate provider Sectigo, which sponsored the Apple proposal, 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." While automation is often touted as the solution to this problem, sysadmins were quick to point out that some SSL certs can't be automated. "This is somewhat nightmarish," said one sysadmin. "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."
Not sure how I feel (Score:2)
It was nice getting an easy ticket to update a cert now and then, but really all of that should be automated and something that doesn't support automatic certificate updates probably needs to be replaced
Re: (Score:3)
With what? And with what money? You buying?
Re: Not sure how I feel (Score:2)
There's a reason standards take ages to update. There's also no reason that web facing and internal can't have shorter/longer times as well. My lightbulb is fine going a year. My webserver isn't.
Re: (Score:2)
Unfortunately, the Apple politburo wants to force the issue for your lightbulb and your webserver. You might want to keep candles and matches on hand.
Re: (Score:2)
I suggest using the money saved by sacking the incompetent that got that equipment in the first place.
Sometimes the cure is worse than the disease (Score:5, Insightful)
I've seen this sort of thing over and over again as protocols are removed from browsers, etc., with no option to just ignore the issue, with the result being that people have to use old versions to manage embedded appliances or 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 (like forgetting you're in the old browser and googling for something), but it would have been completely secure because the appliance or old device is in some disconnected network where no one is snooping on the traffic. I had this with UPSs, printers, data acquisition systems, lab testing equipment, etc.
This move will result in more expired certs, meaning more people will be trained to ignore expired certs, meaning they won't notice that the cert wasn't just expired but replaced. 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...
Re: (Score:2)
Re: Sometimes the cure is worse than the disease (Score:2)
Certs can be automated. People adding another 1 to password111111111111111 shouldn't (but can)
Re: (Score:2)
Certs can be automated.
You must be thinking of your home servers. Try automating cert renewals on an F5 BigIP or an A10 load balancer, which are the kind of appliances most of the world runs on.
Re:Sometimes the cure is worse than the disease (Score:4, Informative)
I've seen this sort of thing over and over again as protocols are removed from browsers, etc., with no option to just ignore the issue, with the result being that people have to use old versions to manage embedded appliances or old stuff that is no longer being supported.
See also Debian bug #1076544 [debian.org], where removal of the older TLS and SSL protocols from OpenSSL made it impossible to sync music to an old iOS device. (An iPod Touch 2nd Gen in my case.)
Re: (Score:3)
"Tell me, is the sky falling"
Tell me, why don't you ask Apple that?
Why so long? (Score:5, Insightful)
Heck, if they're going to make it that short, why not just make it, like, 3 hours. Go all out with your arrogance, Apple & Google!
Re: Why so long? (Score:2)
If it can really be automated, I don't see why not.
Re: (Score:2)
If it can really be automated, I don't see why not.
That reply was to:
why not just make it, like, 3 hours.
I want to see the sign of sarcasm in your post, but I don't, so I'm wondering if it's ignorance. I wonder how often you chance SSH server keys.
Re: (Score:2)
I wonder how often you chance SSH server keys.
You just outed yourself as clueless there. Good job!
Re: Why so long? (Score:2)
Re: Why so long? (Score:2)
Security isn't cheap.
Re: (Score:2)
Same here. But apparently some people are incompetent and hence deeply scared of change. All this will do is getting rid of some "sysadmins" that really do not deserve to be called that.
Re: (Score:2)
That's actually the exact point. The stated end goal here is to eventually have the validity period so short that expiration largely takes the place of revocation, and ideally, so that browsers no longer have to deal with certificate revocation at all.
90 days and 45 days are and arbitrary middle ground designed to cause enough pain that people who can automate now will do so, and that systems preventing that automation will start getting gradually replaced, but they aren't so short (yet) as to be completely
Re: (Score:2)
However, I don't believe that Apple or anyone else should be forcing that onto server admins. No matter the intent. As at the end of the day these kinds of things require money to be spent, and if you're not willing to pay for everyone, you shouldn't be demanding that others be forced to. (Short of a passing general vote for the new TAX you're demanding.)
Re: (Score:3)
OCSP is quite broken and vulnerable to attacks. When I teach it to my students, I almost feel like a comedian.
Re: (Score:2)
That's actually the exact point. The stated end goal here is to eventually have the validity period so short that expiration largely takes the place of revocation, and ideally, so that browsers no longer have to deal with certificate revocation at all.
My take as well. Certification revocation is deeply broken at this time and probably cannot be fixed anytime soon. And since every running HTTPS server has access to its secret certificate, hacking a certificate is as easy as hacking a web-server.
Re: (Score:2)
Load on Let's Encrypt servers.
There goes certificate pinning (Score:5, Interesting)
Certificate pinning was a useful tool to track all kinds of iffy activity (MITM, redirections etc). It does, however, rely on certificates being fairly long lived. The shorter the cert lifespan, and the more changes occur naturally, the less useful it is (and the more users are accustomed to certificates changing "under them" and therefore less protected). I guess the 3 letter agencies should like this plan.
Re: (Score:2, Insightful)
All clues point to NSA being the sole consumer of Apple's on-die backdoor.
So, yeah, quite a cozy relationship.
Re: (Score:3)
Certificate pinning was a useful tool to track all kinds of iffy activity (MITM, redirections etc). It does, however, rely on certificates being fairly long lived. The shorter the cert lifespan, and the more changes occur naturally, the less useful it is (and the more users are accustomed to certificates changing "under them" and therefore less protected). I guess the 3 letter agencies should like this plan.
Certificate pinning was always a mistake anyway. You should just pin the public key. That should basically never change no matter how many times the cert gets reissued, because if it does, that's suspicious. By contrast, nobody should give the slightest crap whether a different CA signed the same key; the fact that it's the same public key presumptively means your communication is with the same company or individual.
Automate or Proxy (Score:4, Interesting)
As mentioned, Let's Encrypt users have been automating this for a long time now, so we have little sympathy for those complaining. However, I have a printer that uses a https interface, but uploading a certificate is a manual process, so I just skip it. I found another workaround: I can proxy it through Apache. I tell Apache to ignore the certificate (it's internal, so I don't really care), and when I connect through Apache, it uses my automated certificate, so my browser is happy.
In a pinch, you could stick a Pi in front of any such device to proxy the https interface and call it a day.
Of course, there are some devices that are very unfriendly with such proxies, but usually it's not that bad.
I ran into this because I was creating a proxy anyway so that I would have a way to access all my internal devices when away.
Re: (Score:2)
I found another workaround: I can proxy it through Apache. I tell Apache to ignore the certificate (it's internal, so I don't really care)
That is such a short-sighted view on the situation. Think about people outside their homes in the corporate world having to do that (and not only to printers). We're talking about all sorts of network appliances: VPN servers, load balancers, proxy servers, etc. None of these devices can use Let's Encrypt. Now do you realize what kind of a nightmare this would be for sysadmins?
Re: (Score:2)
As mentioned, Let's Encrypt users have been automating this for a long time now, so we have little sympathy for those complaining.
Not everyone uses LE.
Re:Automate or Proxy (Score:5, Insightful)
As mentioned, Let's Encrypt users have been automating this for a long time now, so we have little sympathy for those complaining. However, I have a printer that uses a https interface, but uploading a certificate is a manual process, so I just skip it.
So you're saying that even as a home user you found a case not covered by automation, to say nothing of the actual highly specialised equipment that can't be generically automated which makes actual important networks around the world tick.
While you show no sympathy you're actually pointing out the problem with this is even worse than imagined. No one cares about your shitty printer, but we'll be coming to chop your balls off if you decide to play cowboy with security on a layer-4 load balancer of a critical network.
Certs Gone Wild (Score:5, Insightful)
Android has basically made it so that you need root to trust an in-house CA.
Guess what, Bucko, I trust our airgapped CA more than the Hong Kong Post Office.
These guys have gone retrograde on their anal "Security" restrictions.
Re: (Score:3)
On Android only Google / Device Manufacturer is fully trusted. The closest you can get with a user provided CA cert is a custom ROM installed to
Why? (Score:5, Interesting)
Re: (Score:3)
Re: (Score:3)
I think the attack scenario is not so much against a specific certificate. But if the signing organization's key gets compromised, we can be sure that certificates signed by it will die out within 45 days of the compromise being detected.
Prediction - if this goes through (Score:2)
I'm betting a significant percentage of entities just start generating a single wildcard cert every 45 and deploying that to every one of their machines. Yes, this means they'll be pushing the private key everywhere as well - or maybe even reusing the existing private key, over and over.
I'm a little surprised Apple put this forward, since I'd heard there was already a significant desire on Google's part to make this move.
Re: Prediction - if this goes through (Score:2)
Is this the end? (Score:2)
Question: Is this the end of pubkey encryption?
I means seriously, how else could it end? If it was suddenly discovered to be insecure at the fundamental base of the technology... What steps could you take? How fast could you wind it down and move people away from it?
In light of:
https://it.slashdot.org/story/... [slashdot.org]
-T
Re:Is this the end? (Score:5, Insightful)
Installing a CA onto a device was supposed be a conscious choice made by the device owner / system admin who was willing to trust the CA's creator. Of course in the era of Grandma that was never going to work, and big business really wanted a way to automate distribution of encryption keys. So the current system of pre-seeded CAs bundled with the OS / App / etc. was implemented as a workaround. Keep in mind this was decades ago. Well before Social Media was a thing for all of you young-ins out there.
This move by Apple is just another screw tightening on a system that was never designed to work like this in the first place, (what else is new in IT Security?), and the sysadmins are right to complain. If Apple wants a secure automated key exchange system, they can go build one with all of those 30% app store payment cuts they take on every purchase.
Re: (Score:2)
Combining encryption and authentication into one mechanism is where this went off the rails.
Using dh_anon (-like mechanism) and then having a (or multiple) mechanism to verify the remote's identity. But no, we tied everything to the SSL handshake.
We could have had secure connections without passive eavesdropping leaking info (SNI field... Encrypted Client Hello is a horrible botch.)
Not to mention now it takes one injected rogue CA to MITM all SSL connections.
Caddy Reverse Proxy (Score:2)
Will take care of certs automatically. No muss no fuss.
Reminds me of the whining when XP died. (Score:4, Insightful)
Solving of security problems that manifest because things are getting outdated or vulnerable is a constant battle.
Back in the days of WinXP I remember admins and operators complaining non-stop OMG you can't cut XP off. Do you understand the problem that will cause. Etc. Etc. It was like they had no warning at all. In the case of XP warnings about it's demise last years. But yet still people whinged. Remember XP at the time was basically a giant bot net.
Shortening certificate ttl is required. Compromised certs are a common component of intrusions around the world. Just because the current lifespan enables manual maintenance is no solid reason not to shorten the certs ttl. Rather it's precisely the reason to shorten the ttl. The manual component of renewal is a primary cause of certificate leakages and poor certificate management practices.
Yes this will cause pain in the short term. But it's the nasty bandaid that needs to be pull off.
Re: (Score:3)
Shortening certificate ttl is required. Compromised certs are a common component of intrusions around the world.
No, based on that statement alone securing servers against intrusion is far more of a pressing requirement. You're ignoring the real problem of easily compromised servers and claiming that sticking a shiny new CA bandaid on it will fix it.
Just because the current lifespan enables manual maintenance is no solid reason not to shorten the certs ttl
You've deliberately ignored the reasons given because they don't align with your world view. Grow up.
Not every device will be able to get auto updated CA certs, and yes those devices will be used for the foreseeable future. Deal with it. If you don't want those devices
Re: (Score:2)
Shortening certificate ttl is required. Compromised certs are a common component of intrusions around the world.
Anyone who requires it is free to do it, nobody is telling you that you can't. If you want your CA to issue public keys with 30 second validity for the sake of security they should be free to do so.
If people really cared about security following the discovery of a key compromise they would dispense with the validity nonsense altogether and instead focus on reliable operationally sound low latency revocation schemes. The whole concept of an expiring certificate is a blunt instrument, an insecure band-aid t
Apple's Latest Anti-Jailbreaking Ploy (Score:2)
Many legitimate jailbreaking/side loading aids use valid certificates. Apple is again trying to tell people one thing in order to attack the jailbreaking community. They have to be constantly reminded that the court has ruled jailbreaking is LEGAL.
Everybody proxies through Cloudflare (Score:5, Informative)
And Cloudflare doesn't care if your backend connection is unencrypted or uses a self-signed certificate, and there's nothing Apple can do about that, because the browser doesn't even see the backend connection. But sure, let's cut certificate lifetimes to a month, that'll ... do what exactly?
FYI:
> dig +short slashdot.org
104.18.36.64
172.64.151.192
> whois 104.18.36.64
Organization: Cloudflare, Inc. (CLOUD14)
> whois 172.64.151.192
Organization: Cloudflare, Inc. (CLOUD14)
Explanation please? (Score:2)
Can someone explain why you need to TEST a certificate? And why this process - updating certificates - isn't automated?
Not everyone should use public CAs (Score:2)
Most people here are completely missing the point: Public CAs (CAB/Webtrust CAs) are being (mis)used for internal services or so-called "critical infrastructure" (AKA mission critical systems managed by inept vendors where changing a cert takes months).
This is in part what caused Entrust to lose their trusted status in the browsers, they bowed to customers and instead of following the rules and revoking misissued certs, they kept them valid. How much blame goes to Entrust sales for pushing this type of serv
How about long expiry times for keys in a HSM? (Score:2)
Maybe one compromise would be longer expiration dates if the key is generated (with hardware attestation) in a properly certified HSM. YubiHSMs come to mind for starters, and there are others that are enterprise prices. IF the HSM has a higher level FIPS cert then the key expiration is longer.
And yes... nothing is 100% secure, as YubiKeys can have their key material dug out before the recent firmware update, but it requires capture and disassembly of the device. Having a HSM is an ideal balance between h
Churn might lead to more attacks (Score:2)
One trouble with changing things frequently is that we;ll automate the updates, and guess what: we've just increased the attack surface, both software and process.
Depends on the use case (Score:3)
Look, it depends on the use case. For a web server, I have Let's Encrypt, and it does its thing automatically. Short lifespan is fine.
On the other hand, for something completely non-critical (and where automation is not an option), I recently created a cert with an expiry 25 years in the future. I don't ever want to be bothered with it again.
The point is: there is no "right" answer. The lifetime of a cert needs to be left to the people responsible for it.
Fuck Apple (Score:2)
They are the ones who unilaterally shortened the period to 1 year after having lost the vote. I'm perfectly fine with Apple shit not working and directing all complaints to Apple.
Why? (Score:2)
Re:LetsEncrypt users are used to short cert lifeti (Score:5, Insightful)
Yeah, just go out and buy all new stuff chosen from the zero length list of vendors that support automatic updates. Even if the hardware is already firewalled away from the public internet.
How about you and Apple both keep your noses out of other people's underwear?
Re: (Score:2, Informative)
If you don't want new equipment, then you get yourself intimately familiar with WWW::Mechanize.
Re:LetsEncrypt users are used to short cert lifeti (Score:5, Interesting)
How about you or Apple point out even one single incident where shorter expiry would have prevented or mitigated a security breech?
Re:LetsEncrypt users are used to short cert lifeti (Score:5, Informative)
I'm not taking a position on this other than to say LetsEncrypt users are very used to short certificate lifetimes.
Re:LetsEncrypt users are used to short cert lifeti (Score:5, Funny)
Sure. And you'll find no LetsEncrypt certs on equipment that doesn't automate refreshing the cert, even in organizations that use them on their web server.
I'll grant that this is really on-brand for a company that tells people the "correct" way to hold their phone.
Re: (Score:2)
I use LE on all my server (including the one in my sig), and it works great. But if you think LE is the solution to the problem, you've got your head stuck in the sand. In corporate environments, most SSL/TLS delivery mechanisms are not servers, but equipment which provide no way for automatic updates. You can't expect people to just dump perfectly good equipment because Apple decides to shorten the cert lifespan.
Personally, I think everyone should give Apple a bird finger on this one. If most of the ce
Re: (Score:2)
On corporate internal networks there are many certs that are self-signed and often on local network servers. MITM attacks could be done but would require the perpetrator to have access to the inside network.
Of course you may think that it's a bad move to use self-signed certificates but there are a lot of corporate local devices that runs with that because the benefits of a real certificate isn't big enough and other measures can be taken like placing all the sensitive equipment on a subnet protected with a
Re: (Score:2)
I am okay with self-signed certs if that's the only recourse, but I was the CA for our organization for a very long time and generated many certs. All I had to do was provide users with some instructions on a web page ca.xxx.org and users were able trust my CA and then they'd never get any issues with invalid certs for our internal devices. Incidentally, I used to sign the certs for 3650 days, Apple bois be damned.
Re: (Score:2)
thinking that the users won't look at the reason WHY a certificate is invalid
Don't worry, Apple is fully compliant with the 12.1. No User Recourse requirement of HSTS [rfc-editor.org]. So they won't be able to access non-Apple compliant sites at all if the site certificate gets rejected.
Re: (Score:2)
Yes and a colossal pain in the ass it is too.
Re: (Score:2)
I'm not taking a position on this other than to say LetsEncrypt users are very used to short certificate lifetimes.
I'm happy for all the users of non-critical non-specialised pieces of equipment. But don't pretend that just because you got your hobby website on your home computer automated that it is a universal solution for all.
Re: (Score:2)
The only consideration I have is that a shorter lifetime on a server certificate will shorten the time that malicious operators can be active.
There are certificate revocation lists, but they aren't always used.
For everyone else this work with certificate renewal is just a headache unless it can be automated. Add to it all the software license renewal work that now has to be done. Sysadmins worldwide will be tied up doing this tedious annoying work just to keep operations running.
Re: (Score:2)
The only consideration I have is that a shorter lifetime on a server certificate will shorten the time that malicious operators can be active.
If they stole a legit cert once, they can probably steal it again. And if they got a certificate authority to issue an illegitimate cert once, they can probably do that again, too.
Besides, a maximum TTL on CRLs and rejecting all certs from a CA if you are unable to retrieve an up-to-date CRL from a CA before the TTL expires (with some override for browsers that are being deliberately used in a true offline environment for an extended period of time, or better, recognizing when the CRL download fails while
Re: (Score:2)
Can you point to ANY incident EVER where a shortened lifetime would have actually helped AT ALL? NO? Why don't we set zebra traps in all cities just in case a rampaging zebra ever gets out?
Re: (Score:2)
Re:LetsEncrypt users are used to short cert lifeti (Score:5, Interesting)
I haven't heard a case yet where shorter expiry of certs would have prevented or even slightly mitigated the hack.
Re: (Score:2)
Equifax.
It's not just major breaches that this affects, it's also users who fall victim to phishing.
Re:LetsEncrypt users are used to short cert lifeti (Score:5, Informative)
According to this [thesslstore.com], an expired cert CAUSED the breech to remain undetected for longer. Had the cert not expired the damage would have been mitigated sooner.
So that seems to argue for either letting certs last longer (to reduce the risk of expired certs), or to fail softer when they do expire. Or perhaps it argues that the root cause of the equifax breech was not the cert but lax procedures in general.
So I'm still waiting for even a single example of a breech that would have either not happened or would have been less severe if a cert had expired sooner.
Absent that, this move remains in the more harm than good category.
Re: (Score:3)
Yes, the point is to get everyone doing automatic renewals and expiry monitoring, instead of the sysadmin just thinking they will do it manually once a year, or once a decade as used to be typical.
The fact that most browsers now default to big scary warnings and at least two clicks to bypass them helps.
Re:LetsEncrypt users are used to short cert lifeti (Score:5, Insightful)
That just circles back to the problem.
Automation and continuously cycling certificates is great for websites on the cloud.
It will remain a nightmare to IoT, for devices that can't be easily updated, for devices where automation is impractical or impossible, for devices that require validation or recertification after all configuration changes, and other scenarios.
Far too often the global megacorps forget that the entire world is not a global megacorp. There are businesses and individuals with no army of IT folks who can remotely deploy updates to always-on boxes in a data center. It is people going out in the field, manually running commands, and working on each device one at a time in a labor intensive task, sometimes requiring serious work to bring systems down, modify, recalibrate, then bring back online.
Re: (Score:2)
I do not think this is designed to improve the security of a specific certificate or key. I think it's designed to ensure that if the signing authority is compromised, certificates it has signed die off pretty quickly and won't be trusted even by clients that don't have a way to revoke the signer's root certificate.
Re: (Score:2)
I do not think this is designed to improve the security of a specific certificate or key. I think it's designed to ensure that if the signing authority is compromised, certificates it has signed die off pretty quickly and won't be trusted even by clients that don't have a way to revoke the signer's root certificate.
That sounds like the perfect way to brick a perfectly good computer. Just don't update it until the local copy of the trusted roots expire after 30 days. There's no way for it to get new trusted roots because it can't make HTTPS requests. There's no way for it to get a software update because it can't make HTTPS requests. And boom. $9,000 brick.
I'm operating under the assumption that the root certs will still have durations measured in O(years), because I'm pretty sure the entire world would break down
Re: (Score:2)
won't be trusted even by clients that don't have a way to revoke the signer's root certificate.
How many clients are those? Hasn't that been built into every browser since the 90s?
Re: (Score:2)
I do not think this is designed to improve the security of a specific certificate or key. I think it's designed to ensure that if the signing authority is compromised, certificates it has signed die off pretty quickly and won't be trusted even by clients that don't have a way to revoke the signer's root certificate.
The 45 day thing is not for CAs "limits the validity period of Subscriber Certificates. "
Re: (Score:2)
Do certs actually improve security in any meaningful way at all?
They prevent MiTM attacks if you use them correctly. The ISP can't do a MiTM without you installing something from them (or getting something from the browser, like China does).
Why get a public CA cert for something non-public? (Score:2)
> Even if the hardware is already firewalled away from the public internet.
Then just use an internal CA that signs the certs for as long as you want? Why even get a public CA cert for that, if you control everyone talking to it?
Re: (Score:2)
It won't help if the browser barfs on them because it doesn't like the TTL.
Re: (Score:2)
This change doesn't affect your own locally trusted certicates, only publicly trusted ones. So if you have using them for internal systems you can install install your own root authority with expiry dates set to whenever you like.
Re: (Score:2)
That would be true if Apple would MYOB and not dictate how long other people's certs last.
Re: (Score:3)
If you have equipment that doesn't support a way to automatically update a certificate, well then... time to yell at the vendor or switch vendors to those whose equipment is better-designed.
For LetsEncrypt to work, you need your hosts to be accessible from the Internet. I'm using long-term wildcard certs on my IoT devices (such as a TrippLite UPS or an Asterisk-based PBX) that are not reachable from the outside. Updating certs once a year is not a big deal, but doing that once a month is not going to happen.
Re: (Score:2)
Wildcard certs don't need a host to be accessible from the internet.
They're issued with DNS verification. You can use any machine that has the ability to contact LetsEncrypt and update DNS records.
Re: (Score:3)
Wildcard certs don't need a host to be accessible from the internet.
And then I need to manually copy it onto the hosts. Because there's no industry-accepted protocol for certificate provisioning to internal devices (SCEP doesn't count).
no industry-accepted protocol (Score:2)
Re: (Score:3)
For a wildcard cert, you need one Internet-accessible host that can do the ACME-DNS verification.
That host can then redistribute the certificate as needed. My certificate-renewal machine redistributes the certs to a bunch of other machines, some of which are internal-only.
For machines like the TrippLite UPS, I'm guessing updating the cert is annoying and has to be done via a Web UI. That's where WWW::Mechanize or some other web automation tool comes in. Honestly, even if I were updating certs once a ye
Re: (Score:2)
I guess your certs aren't password protected? Or do you recommend that the administrator username and password with the certificate password be stored in plain text so your WWW::Mechanize script can read it?
Do you use the same domain for your private internal servers as your live servers? How do I set an Internet-accessible host on a private/local domain?
The proposal is a solution looking for a problem. Your proposal doesn't fix the problems it creates. It just opens more issues without adding any value.
Re: (Score:2)
Whether or not certs are password-protected is immaterial to how they are updated. Of course, if a password-protected cert is updated, it might take human intervention to enter a password to decrypt it. That could get annoying if it has to be done often.
But there are well-known methods for securely storing secrets (like HashiCorp's vault) so you could automate that too.
Yes, I do use the same domain for internal and external machines. Why not use a real domain everywhere? I don't have to do this; I cou
Re: (Score:2)
For a wildcard cert, you need one Internet-accessible host that can do the ACME-DNS verification.
And then I need to manually copy it onto the hosts. Because there's no industry-accepted protocol for certificate provisioning to internal devices (SCEP doesn't count).
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
(And of course despite Apple suggesting this now, everyone else is pretty much in agreement that this must happen.)
Re: (Score:2)
This is just a race to the bottom. Next Apple (or Google / Microsoft / etc.) will demand 7 day lifespans. Then they'll demand 24 hour lifespans. Then they'll demand 7 second lifespans....
It never ends. All it does prove is that the IT industry in general has no business defining who to trust and when for the entire world as there's no universal answer that works for everyone.
Re:LetsEncrypt users are used to short cert lifeti (Score:5, Interesting)
I use a LetsEncrypt wildcard cert on my machines and it lasts for 90 days. Renewal and redistribution of the new certificates are completely automated, so it's no big deal.
Tell that to the weekend I spend every couple of years after something goes horribly wrong, when I'm trying to debug a system that only lets you make a limited number of requests per day, staring down the barrel of a gun after getting the dreaded email from LetsEncrypt that I've fallen below 30 days of remaining life on the currently active certificate.
No, it's really NOT "no big deal". It's a huge pain in the a** compared with manually upgrading a cert once a year, which is a huge pain in the a** compared with manually upgrading a cert once every five years. Anybody who says otherwise has been lucky enough to never end up on the wrong side of certbot.
Re: (Score:2)
Yeah but that's different. For a couple of reasons - the LetEncrypt CA doesn't expire after that length of time, only the ephemeral cert that was signed. The cert is also intended to be used that way, not (for example) two endpoints exchanging the cert to form trust or purposes certs have baked into their particulars. In addition, browsers presently don't care if certs live longer than 90 days so the rotation doesn't impact on the browser or user experience, not impact on sites whose cert does NOT rotate ev
Re: LetsEncrypt users are used to short cert lifet (Score:2)
Re: (Score:2)
Automated updates are actually another attack surface and introduce more risk. More complexity results in more potential vulnerabilities.
Re: Automate better (Score:2)
Re: (Score:2)
While true, this takes some actual skill to make it work and work reliable. I expect many "sysadmins" are lacking that and are deeply scared of being found out.