The EFF's 'Certbot' Now Supports Six-Day Certs (eff.org) 92
10 years ago "certificate authorities normally issued certificate lifetimes lasting a year or more," remembers a new blog post Thursday by the EFF's engineering director. So in 2015 when the free cert authority Let's Encrypt first started issuing 90-day TLS certificates for websites, "it was considered a bold move, that helped push the ecosystem towards shorter certificate life times."
And then this January Let's Encrypt announced new six-day certificates...
This week saw a related announcement from the EFF engineering director. More than 31 million web sites maintain their HTTPS certificates using the EFF's Certbot tool (which automatically fetches free HTTPS certificates forever) — and Certbot is now supporting Let's Encrypt's six-day certificates. (It's accomplished through ACME profiles with dynamic renewal at 1/3rd of lifetime left or 1/2 of lifetime left, if the lifetime is shorter than 10 days): There is debate on how short these lifetimes should be, but with ACME profiles you can have the default or "classic" Let's Encrypt experience (90 days) or start actively using other profile types through Certbot with the --preferred-profile and --required-profile flags. For six day certificates, you can choose the "shortlived" profile.
Why shorter lifetimes are better (according to the EFF's engineering director):
And then this January Let's Encrypt announced new six-day certificates...
This week saw a related announcement from the EFF engineering director. More than 31 million web sites maintain their HTTPS certificates using the EFF's Certbot tool (which automatically fetches free HTTPS certificates forever) — and Certbot is now supporting Let's Encrypt's six-day certificates. (It's accomplished through ACME profiles with dynamic renewal at 1/3rd of lifetime left or 1/2 of lifetime left, if the lifetime is shorter than 10 days): There is debate on how short these lifetimes should be, but with ACME profiles you can have the default or "classic" Let's Encrypt experience (90 days) or start actively using other profile types through Certbot with the --preferred-profile and --required-profile flags. For six day certificates, you can choose the "shortlived" profile.
Why shorter lifetimes are better (according to the EFF's engineering director):
- If a certificate's private key is compromised, that compromise can't last as long.
- With shorter life spans for the certificates, automation is encouraged. Which facilitates robust security of web servers.
- Certificate revocation is historically flaky. Lifetimes 10 days and under prevent the need to invoke the revocation process and deal with continued usage of a compromised key.
Automation is encouraged, revocation not necessary (Score:3)
This doesn't make sense, does it? Certificates are valid for 6 days, so if my key is compromised, there won't be much damage. However certificates are only valid for 6 days, so it's a practical requirement to automate renewal.
If I automate renewal, doesn't that mean my compromised key is valid forever? Or is cancelling this automaton supposed to work better than revocation? It's certainly going to take 1-6 days instead of being effective right away.
Re: Automation is encouraged, revocation not neces (Score:5, Informative)
You generally generate a new key on every "renewal".
The key is generated on your computer.
So if there's a one-off private key compromise, the next key will be safe again - and the old, compromised one won't be trusted because too old. No need to revoke the old key.
That said, you should obviously fix your security holes that allowed the compromise in the first place, or should stop the renewal job from running until you do, or else you risk having your new keys compromised time and time again, too.
Re: (Score:2)
Typically your key would be generated on the machine where it's used, so if that machine is compromised so is the key, or the attacker could interfere with the renewal process (eg by causing it to generate a known weak key every time).
About the only change would be that if you discovered the compromise you could fix the problem and then wait 6 days instead of immediately revoking the key and generating a new one. Personally i'd want to revoke and renew immediately rather than leave a 6 day window of vulnera
Re: Automation is encouraged, revocation not nece (Score:3)
I think we're talking about different things here.
This isn't automatic mitigation, it's only about the necessity of revocation after the comprising and fixing have been detected.
You're not leaving the system "compromised for 6 days", you're doing whatever you need to do to fix the compromise, and then can restart. Your new system will be safe & sound right away (provided you've actually fixed your hole). The only thing that will happen, is that there will also be another, older key for your doma
Re: (Score:2)
The question then becomes: how much of the communications *before* the systems compromise can now be decrypted after-the-fact?
The answer is the age of the active private key.
For example, if we both run a web server that was compromised by the same exploit yesterday, and we patch it at the same time today, a 6-day certificate age on my server means only communications over the week prior to the compromise can be decrypted, where a typical CA cert on your server means up to an entire year of communications prior to exploiting your server can now be decrypted.
I believe this is no longer true as because of the (somewhat mind-bending) "Perfect Forward Secrecy (PFS)" feature/concept which is mandatory in TLS 1.3. (https://www.thesslstore.com/blog/perfect-forward-secrecy-explained/ ). It makes it that you can't decrypt recorded/intercepted sessions even with a compromised server cert private key.
so i believe the risk of losing a key now is only that your server can be impersonated. And cert length is about how long that window of exposure is.
Re: (Score:2)
No w/ Diffie-Hellman key exchange (really "generation and exchange") the session key used for bulk encryption of the data never appears on the wire in any form, even encrypted, so even if you have the private key of the server you can't decrypt the stream even if you see it from the first packet to the last.
https://en.wikipedia.org/wiki/... [wikipedia.org] ... the "mixing paints" example drove it home for me a couple of years back:
https://jamesmccaffrey.wordpre... [wordpress.com] (idk the origin of the paint example; this is just a link
Re: (Score:2)
So we still need revocation in order to inform the CA to blacklist the keypair to make sure an attacker can't request renewal of the cert in between the time we detect the compromise and the time the compromised resource and systems are fully contained and replaced.
Air-gapped intranet (Score:2)
Typically your key would be generated on the machine where it's used
And atypically, the server is on an air-gapped private intranet, and someone needs to use another Internet-connected machine to request a certificate and then copy it to the intranet server using physical media. Is it better to generate the private key and CSR on the machine performing the request? Or should it be generated on the air-gapped server, requiring sneakernet both to and from the Internet-connected machine?
Re: (Score:2)
If it's an air-gapped private intranet who is connecting to it such that it needs Internet valid certs?
If you also control all the clients it's probably easier to deploy your own internal CA and trust that CA's cert and then do things internally.
If for some reason you don't control the clients and you need server certs from an Internet CA then generating the key pair and the CSR where it's used is marginally more secure because then the private key only exists in that one place. It isn't ever copied anyw
Re: (Score:2)
If it's an air-gapped private intranet who is connecting to it such that it needs Internet valid certs?
If you have an internal web application, you need to deliver it over HTTPS, or it'll be locked out of half of the JavaScript APIs because these APIs are restricted to secure contexts.
If you also control all the clients it's probably easier to deploy your own internal CA and trust that CA's cert and then do things internally.
Last I checked, it was difficult to install a private root certificate on a bunch of devices running Android or iOS/iPadOS, especially devices brought in by visitors to your premises. Consider, for example, the case of museum guests who connect their phones to the museum's private WLAN to run a web application that it makes ava
Re: (Score:2)
Heh, i was going to mention the BYOD case above because that use case you'd definitely need it. There's no way, as a user, i'm trusting some rando CA cert when i come to your facility.
But once you're allowing these potentially hostile devices on the WLAN is it worth it to have the intranet air-gapped to begin with?
Re: (Score:2)
This could be true for a small site with a single server that is both the gateway (nginx etc.) and the web server. If an attacker owns your server, then all bets are off, and this is hardly a surprising result. The lesson here is: Don't let an attack take over and own your se
Re: Automation is encouraged, revocation not neces (Score:3)
A standalone public key doesn't have inherent validity. It's only valid during the validity period of the certificate that embeds it. So no, your old public key would not be valid forever.
When obtaining a new certificate, it's your choice whether to generate a new keypair, or reuse the old one. IMO, it is a computational waste to generate a new keypair every 6 days. It really only needs to be regenerated if the private key was known to be or at risk of compromise. The only reasoning for short validity perio
Re: (Score:2)
Until someone hacks your certbot process..
Re: Automation is encouraged, revocation not nece (Score:2)
In which case the new keypairs would probably be at risk, too. I don't think the frequent renewal helps anything. And there is a lot of downside.
Re: Automation is encouraged, revocation not nece (Score:2)
How much CPU time is required to generate a new key pair? What percentage of six days is that?
Re: Automation is encouraged, revocation not nec (Score:2)
It's not just the keygen. Clients that had cached SSL sessions or tickets may need to renegotiate. This is also not at the scale of just one server or client, but all of them. The relative percentage isn't my point. But it still adds up to a waste of energy.
The energy wasted administering all this madness is worse, though. Fixing revocation would have been much better.
Re: (Score:2)
it is a computational waste to generate a new keypair every 6 days.
It's a "waste" that should be ignored, because it is nothing but de miminimis. The compute time to generate a new keypair is minimal.
And eliminates a major issue for the case of an Unknown leakage or exposure of your secret key. For example; if your key has been exposed in an unknown breach, Or if the key has been weakened by some means unbeknownst to you - generating a new keypair resets the clock on anyone who might be currently atte
Re: (Score:2)
Those are completely legitimate concerns. I just don't think that generating a new keypair every 6 days is the solution to them.
If your private key is on a compromised file system, fix the permissions. If it's a kernel exploit leaking the data, update the kernel. If your CPU is leaking private key data, enable all available mitigations for it. If you can afford it, generate a non-extractible private key in an HSM. If it's an SSL stack timing attack leaking key bits, update your SSL stack.
If the key exchange
Re: (Score:2)
While searching for that vulnerability, Gemini told me that 1 is not a prime number. No wonder it can't find the CVE.
https://drive.google.com/file/d/1XyKCWRkvZMpeluUXKjaqZ4AYZbUS_tIN/view?usp=drive_link
Re: (Score:3)
These morons. I swear. They can not tell the difference between an e-commerce site which IS NOT GOING TO BE USING LET'S ENCRYPT IN THE FIRST PLACE, and some shitty blog hosted on a $10/mo webhost running shitty wordpress that doesn't even need to be running SSL. Fricken Google made web into this ad-barnicle'd nightmare and all SSL does is make it so that it's harder to block ads by any means that doesn't involve degrading the security model.
Everything was working fine until then.
Re: (Score:1)
bingo
HTTPS everywhere was always about making the Internet safer for ad guys, and big tech that wanted to force everyone to use their policy controls and subscribe to their vision of acceptable content rather than any organization or house hold level filtering working.
LE was major Trojan horse and the InfoSec people got duped hard into selling.
Re: (Score:2)
These morons. I swear. They can not tell the difference between an e-commerce site which IS NOT GOING TO BE USING LET'S ENCRYPT IN THE FIRST PLACE
Ecommerce sites actually DO use LetsEncrypt, and some use their peers and similar such as Google Trust Services [pki.goog] which is basically the same thing as LetsEncrypt.
Re: Rationale (Score:2)
That can be tricky if you have multiple servers on a host with no Certbot plugins, and DNS without any Certbot plugins.
They've made certain setups easy to automate, but more complicated ones actually require scripting around the provided tools.
Honestly, I think they should go back to the drawing board on the ACME protocol. The fact that no one uses it directly and there are few alternate providers supporting it leads me to believe it's too complicated and isn't serving its purpose well.
Let's Encrypt positio
Re: (Score:2)
Re: Rationale (Score:2)
While you may be right, I think it's notable that they're adding an extension for profiles, finding the current implementation to be deficient.
https://datatracker.ietf.org/d... [ietf.org]
I don't know if profiles would do what I would really like to see though, which is an API key and a simple GET /acme/certs/myfoo.com/2026/01/01 to get an updated cert for myfoo.com that expires in 2026.
Re: (Score:2)
So you have a bash or Powershell script that moves the certificate to the correct place, changes binding as a appropriate to use it, and restarts the affected services.
What's the problem with that, other than having to write and test the scripts?
Re: Rationale (Score:2)
You've skipped the step where you generate the cert, requiring you to somehow verify domain ownership. DNS is the go-to solution, but that doesn't work if your DNS provider doesn't have an API. And even if they do have an API, if it doesn't have a Certbot plugin, implementing that API may or may not be straightforward.
Re: (Score:2)
Who on earth *isn't* already automating letsencrypt?
Quite a few scenarios can't do it, actually.
If your scenario fits in the box --- and the vast majority of cases fit in the box --- then the ACME protocol works great. Publicly accessible, ability to modify mainstream DNS TXT record, and public access to port 80, and able to get online on the public internet periodically at least once every 3 months, you're great. If you're in the most typical scenario it works just fine. Box in a datacenter, system runs in an always-on network, using any of the major DNS p
I hope everyone adopts this! (Score:2)
and that then Let's Encrypt has a once in a lifetime 4 day failure.
Re: (Score:3)
What happens in countries that have all their internet links cut at the same time?
I'm still looking for one real world example where a short cert expiry time solved a problem.
6 days? Way too long (Score:5, Funny)
This is just security theater. Intelligent sysadmins won't be satisfied until 6 nanosecond certificates are allowed!
Re: 6 days? Way too long (Score:2)
Re: 6 days? Way too long (Score:3)
Every connection needs a new cert. New certs must also be re-negotiated on each new request
Otherwise the terrorists win.
Re: (Score:2)
Every connection needs a new cert.
Every packet. Then we're double-plus winning!
Re: 6 days? Way too long (Score:2)
Shit bro, my solution was like an open telnet connection. I stand corrected.
Re: (Score:2)
Every byte?
That's what OCSP stapling used to be for (Score:3)
New certs must also be re-negotiated on each new request
Online Certificate Status Protocol (OCSP) was invented to approximate this. However, because OCSP requests from clients let CAs surveil viewers' traffic, most use of OCSP switched to "stapling." Every few hours, the server would contact the CA and ask it to sign a new OCSP response, and then the server would include the response alongside the certificate at the start of the TLS connection. Support for short-lived certificates appears to compensate for Let's Encrypt no longer providing OCSP as of August 2025 [letsencrypt.org]
Pointless. (Score:5, Interesting)
> If a certificate's private key is compromised, that compromise can't last as long.
If your key is compromised, it doesn't matter if it's 6 days, 60 days or 600 days because by the time your certificate is renewed, the baddie has already either installed C2, backdoor, new key or exfiltrated any data they wanted.
Another useless "feature" that adds more work to already overburdened admins. This whole thing sounds like it was decide by people who live in their little echo chambers, do everything in "in the cloud" and have _zero_ understanding of what a lot of admins have to deal with every day.
Also what happens if LE is down for a week or two?
Re: (Score:2)
Chances are your key is only stored in the places it's being used/renewed, so the chance of the key alone being compromised and not the scripts doing the renewal is very low.
Even then if a way to leak the key is found, that doesn't mean the leak will be immediately detected.
Once the compromise is detected you have to clean it up, and part of that can easily include revoking a long term cert. Revoking a cert is minimal effort compared to triaging and fixing a compromise.
Re: (Score:1)
If your key is compromised, it doesn't matter if it's 6 days, 60 days or 600 days because by the time your certificate is renewed, the baddie has already either installed C2, backdoor, new key or exfiltrated any data they wanted.
That's because the key affects *past* communications, not future. "By the time ..." refers to a future event, so of course it isn't involved here. You know this.
It can matter a lot because that's the difference of 6 days or 600 days of decrypted communications from *before* the system is compromised.
Re: (Score:3, Insightful)
Another useless "feature" that adds more work to already overburdened admins.
Only incompetent admins are overburdened. All others just update their automated tools to the new cadence.
sounds like it's designed to facilitate malware (Score:1)
You have a valid certificate that disappears in six days. What genuine site would have any need for this? It's for pulling off a quick scam, hello, goodbye. I promise that the Brooklyn Bridge is in your email.
Re: (Score:2)
This doesn't at all help malware, malware would be content to have infinite validity for all it cares. The certificate expiring doesn't make it somehow "invisible" or anything, everything is still plain to see, it's just instructing people not to trust it.
It is simply meaning that the associated private key to authenticate your site to users won't be useful for longer than a week, with automation running every day or two to cycle your key material. Your site/service is always visible but just with cycling
Re: (Score:2)
I would not go that far but it is completely solving the wrong problem.
The whole reason everyone is pushing these short lifetimes is because there is not good solution to revocation checking, well there is OCSP works fine or could in any situation where the systems can connect to the outside world often enough to make automated certificate renewal happen once a week!
The short life approach is fundamentally wrong because it requires we ask the question "how long is to long for a compromised key to be valid?"
OCSP is found to facilitate surveillance (Score:2)
at less than one week lifetime you are rapidly approaching overhead and connectivity problems not so different from OCSP and CRLs.
The problem with OCSP is that a government can compel the operator of an OCSP responder to log requests. That's why Let's Encrypt is shutting down its OCSP responder in favor of a CRL [letsencrypt.org].
Obsoleting Browser locked certificates (Score:3, Interesting)
It seems the big browsers have local certificate caches - used to catch MITM attacks that swap browser certificates mid-connection.
If you have a 6 day cert, it would mean your browser needs to update this cache every few days. Since it's supposed to be a pinned cache to prevent malware from easily replacing it, it's usually built into the browser binary and thus the updates require basically a daily update of your browser.
Or users suffer through endless "The certificate is invalid" messages which just gets them to ignore that message when it crops up
Not good enough (Score:2)
This is all theatre. What people really want are
- free certificates for home appliances behind NAT
- free certificates for signing
Re: (Score:2)
All this is easy as long as you control your own domain. It is just kind of absurd to need to do it for local hosts; the pain/reward is pretty much infinite.
Re: (Score:1)
Is it easy?
I don't think it is easy. My smart-tv won't accept the cert on my internal webserver. There is no way that I am aware at least without involving a soldering iron to insert my CA certificate into its trust store.
Ditto for every other little IoT box that arrives.
The situation on contemporary mobile phones is better but unless you have like an MDM package, they don't make it easy to install a private CA as trusted. You can do it, but the next iOS update comes a long and suddenly it does not like so
Re: (Score:2)
I do it with Letsencrypt DNS challenge and not a local CA. You can do wildcard certs if you just want one for everything. It doesn't really improve security though and that is the bigger problem.
Re: (Score:2)
NAT is a nasty kludge, use IPv6.
You can easily generate certs for hosts which are not publicly reachable if you control the DNS, and certbot has various plugins for that.
You can create your own CA and deploy its root on your devices if you only want to access the devices yourself.
Re: (Score:2)
Re: (Score:2)
There are plenty of places which will give free subdomains...
Some routers (ex fritz!box) also come with a built in dyndns service and free subdomains.
Re: (Score:2)
- free certificates for home appliances behind NAT
If you are referring to using SNI to publish services behind a NAT to the internet, then that's wholly within the scope of Let's encrypt, they are oblivious to the backend details. You can get many certificates for a singular public IP, it's based on DNS name not IP.
If you are referring to internal only services, then why not use a private CA?
If a private CA is unacceptable, and you wanted to use your domain for some exclusively internal services, but using a well trusted CA, then just externally stub out t
Re: (Score:2)
On the "never fix revocation", the industry has been trying for 25 years and the two basic approaches (CRL and OCSP) are pretty bad with no good alternative in sight. From a practical perspective, it's time to admit defeat and at least mitigate the problem.
The industry has been sitting on its hands for decades. The obvious and trivial solution is to publish a global list of security related revocations. Not the massive revocation database of administrative bullshit but the good enough list of keys that were actually compromised and pose an actual threat to real world users. Browsers could periodically update lists and or updates can be provided in-band during TLS handshake.
I'm curious what trivial structural changes you imagine to further mitigate the issues with x509 and DV certificates. Whatever ones I can imagine all have downsides that are generally even worse than the status quo, generally from a practicality standpoint.
Registrars have an existing trust relationship with domain owners, the solution is t
Re: (Score:2)
The thing about the certificate revocation lists is that it's not a particularly scalable approach.
If a big list of certificates were manageable, then why would we have been doing certificate signing in the first place, we could just have a really really 'global known hosts' sort of file. That wouldn't work because it's just too much. The certificate revocation task should be *smaller*, but still fundamentally similar as every random little internet service could arbitrarily revoke out of legitimate concer
Re: (Score:2)
The thing about the certificate revocation lists is that it's not a particularly scalable approach.
It doesn't need to be scalable, there are not that many sites getting owned.
If a big list of certificates were manageable, then why would we have been doing certificate signing in the first place, we could just have a really really 'global known hosts' sort of file.
A list of compromised keys is smaller than every public key of every site on earth. All that is required is a means of tombstoning a small number of actually compromised keys.
That wouldn't work because it's just too much. The certificate revocation task should be *smaller*, but still fundamentally similar as every random little internet service could arbitrarily revoke out of legitimate concern or paranoia, and could even do so repeatedly (Imagine someone deciding they want to use revocation to manually enforce a 6 day limit, and so they contribute a set of revocations every week that can't age out until the actual expiry). People will self-revoke even without a provable security incident, and the certificate authorities are in no place to evaluate the merit of a revocation.
This is absurd, there would of course be a process with rules, attestation and fees to affect revocation of keys that pose an actual threat to real world users. If a site owner attests to being compromised regularly there should be an established protocol for
make it realtime expire (Score:3)
have the server use a new certificate from Let's Encrypt for every request.
Re: (Score:1)
For better security, to make sure no certificate can ever be used maliciously, one could go one step further and invalidate the certificate right away.
6 day certs are a sign something is wrong (Score:4, Interesting)
Effectively it's saying "trust me but only for up to 6 days".
Go figure.
It's BS that it's more secure than 1 year in practice. If you get pwned it doesn't matter whether the cert is 6 days or 6 years. You think the hacker is going to turn off cert renewal?
The real technical advantage is there's a lower need to handle revocation.
However, guess what, in the real world, in many cases self signed certs that are valid for decades are just as safe if not more so (because you don't need a connection to the Internet). Basically the client only trusts ONE cert, no other. If you discover you get pwned you replace that one cert with another. If you never discover you got pwned, a 6 day cert doesn't save you either. Also zillions of ssh servers are set up this way - you set up the trust the first time, and it's valid till you decide it's not. I don't hear reports of this being a huge security problem in real life.
much of the CA stuff is basically a money grab and shorter duration certs are a solution to fix the problem they created in the first place.
If the browser bunch truly care about security, browsers would
1) allow you to do the ssh style stuff (trust this self-signed cert indefinitely but warn me if it ever changes).
2) warn you by default if the CA for a cert changes unexpectedly. Or optionally if a cert changes unexpectedly.
.
Re: (Score:2)
Well, the threat it mitigates is that someone who gets the private key for a cert can impersonate that server until the cert expires (or the cert is revoked if clients use CRLs).
So there is _some_ advantage e.g. that your period of vulnerability is reduced in cases where let's say there a cert's private key in some backup that gets out or a someone has it on a laptop or in an email that gets compromised or whatever. Or maybe someone gets an encrypted backup but it takes them a while to crack the key to the
Re: (Score:2)
So recall back to the 'heartbleed' vulnerability. In it, hypothetically, an unauthenticated attacker could have gotten your private key, but otherwise had been unable to compromise your site.
So now, if they have that key material and hijack the connection of one of your users and that certificate is still valid (because the client isn't doing CRL or the operator was totally oblivious to the fact their private key got retrieved once). The window of opportunity for that certificate being months long is pret
Re: (Score:1)
1) it might be too easy for scammers to get people to click through.
Which is why the heartbleed private key stuff you mention is unlikely to be significant problem in real life. The operators who care and need such levels of security would have reissued their certs after patching their web servers. The oblivious ones would still be vulnerable to heartbleed.
The real reason for CA signed certs is so that users don't get scary warnings and the auditors don't slap you - it's all security theater for as long as browsers don't warn you by default if CAs change.unexpectedly (e.g.
Re: (Score:2)
The oblivious ones would still be vulnerable to heartbleed.
There are plenty of small service operators that have automated updates but might not be supremely aware that they need to proactively get their certificate revoked. Updates can fix code related vulnerabilities to seal off future attacks, but we cannot as easily autosense a need to revoke certificates.
I agree that the "any CA is as good as another, even replacing" model is pretty busted.
The argument about people aren't imitating the verbatim name *anyway* so why do we need to be so strict about the validat
6 Days? WTF? (Score:2)
Re: (Score:2)
Re: 6 Days? WTF? (Score:2)
Re: (Score:2)
also w/ the parent. At my last place we had it all automated for a low double digits of certs and it was mostly fine but still broke about 2-3 times a year for one reason or another.
And when it does it needs to not be an issue for at least 5 days, preferably 6, so that if it happens on the Wed afternoon before Thanksgiving (or equivalent ) we can choose to deal with it on Monday when we get back.
Yeah, we had 24/7 coverage and we've fixed various things in the middle of the night on Christmas etc. but why
I hate this (Score:2)
I have several VMs that only boot up weekly or monthly for a few minutes and then shut back down. If they fail to update the certificate then the next boot the web interface is inaccessible. It pushes me back to insecure protocols, which even on my LAN I consider a stupid risk.
Re: (Score:2)
Re: (Score:2)
"This is entirely optional." for now.
recall from about 7 months ago:
Apple wants to shorten SSL/TLS security certificates' lifespans, down from 398 days now to just 45 days by 2027, ...
(https://apple.slashdot.org/story/24/10/15/2324206/sysadmins-rage-over-apples-nightmarish-ssltls-cert-lifespan-cuts )
Ultimately they got beaten back to 90 days, iirc. Chrome and Apple have been in a race to the bottom on this for years and i don't expect them to stop.
Re: (Score:2)
I would assume if such a process were applicable to an externally facing service, that the startup process would include an automated renewal attempt? If you are saying instead that you have sites with certificates that are externally managed by automation run on occasionally booting VMs, then if those VMs are automated, wouldn't you just increase your schedule to accomodate? If you are manually updating your certificates, it's already got to be obnoxious to remember to do it in a timely way for 90 days.
If
Internal CA on smart TV (Score:2)
If this is for internal services that aren't on the internet, then let's encrypt seems like it would likely not be relevant to you, and you'd be using an internal CA.
As DarkOx wrote in this comment [slashdot.org]: How do I get a smart TV (say, Roku) to trust an internal CA?
Blame Chrome (Score:1)
Chrome doesn't use or respect CRLs,
i had a customer who couldnt connect to their SAAS provider using Firefox they just got a cert warning and no option to override, so i dug in and found that their cert had been revoked, their tech support was "use chrome, it works fine, cert hasnâ(TM)t expired so we good"
what i learned was that cert can be revoked all you like and Google's Chrome will keep on trucking like nothing has happened, no warnings, nothing.
Re: Blame Chrome (Score:5, Interesting)
My code is likely to blame for those strict revocation checks in Firefox. I authored much of the CRL revocation checking code in Mozilla NSS a few decades ago. Better safe than sorry.
I'm not responsible for the lack of override in the UI, though. The underlying APIs certainly allowed override.
Early Chrome used NSS too, and would have enforced the same checks then.
But no more. Enshitification comes to mind.
Less secure not more (Score:3)
This whole house of cards is not fit for purpose and needs to be put out of its misery.
1. Overlapping trust anchors increase risk of global compromise for no reason.
2. No linkage between domain ownership and certificate issuance.
3. The whole system is STILL based entirely upon INSECURE indications from INSECURE protocols.
4. Meritless rapid expiry makes locally offloading trust from CAs more difficult.
5. More excuses to never fix revocation as if allowing compromise to persist for days is in any way acceptable.
6. Lack of maturity in automated renewal protocol with multiple examples of recent breaking changes for avoidable reasons.
7. Creates an avoidable choke-point for system failure or attack to result in loss of availability of millions of sites.
I still find it absurd all any attacker ever has to do is get access to the Internet link to the site. Not even compromise a single of the sites systems in order to be in a position to fully compromise that site. DV certs are not far removed from ADH.
What is especially sad is most of the problems can be fixed with trivial structural changes to the process.
Re: (Score:2)
With regards to this specific capability, I don' think it decreases security any, though most of your points are more broadly about DV certs or the x509 approach in general.
On the "never fix revocation", the industry has been trying for 25 years and the two basic approaches (CRL and OCSP) are pretty bad with no good alternative in sight. From a practical perspective, it's time to admit defeat and at least mitigate the problem.
I'm curious what trivial structural changes you imagine to further mitigate the is
Re: (Score:2)
On the "never fix revocation", the industry has been trying for 25 years and the two basic approaches (CRL and OCSP) are pretty bad with no good alternative in sight. From a practical perspective, it's time to admit defeat and at least mitigate the problem.
I'm curious what trivial structural changes you imagine to further mitigate the issues with x509 and DV certificates. Whatever ones I can imagine all have downsides that are generally even worse than the status quo, generally from a practicality standpoint.
Registrars have an existing trust relationship with domain owners, the solution is to use it.
1. Ditch CA altogether move to DANE
2. Have registrars hand out certs as a normal part of domain ownership
3. If you want to keep CAs the registrars issue some sor
Re: (Score:2)
I feel like going to DANE is much bigger than what I'd call a "trivial" structural change. Pivoting to the DNS ecosystem would be a rather significant technical and logistics challenge. The DNS ecosystem is so fragmented that DNSSEC deployment was a practical failure, and you really need the DNS ecosystem to be in good lock step before even considering it as a mechanism to supersede the x509 status quo.
It might have been nice if we had started from that position back in the 90s when it was still early enoug
Re: (Score:2)
I feel like going to DANE is much bigger than what I'd call a "trivial" structural change. Pivoting to the DNS ecosystem would be a rather significant technical and logistics challenge. The DNS ecosystem is so fragmented that DNSSEC deployment was a practical failure, and you really need the DNS ecosystem to be in good lock step before even considering it as a mechanism to supersede the x509 status quo.
Until relatively recently DNSSEC was impossible to deploy without becoming a lightning rod for severe DNS amplification attacks.
the scammers will love 6 day certs (Score:2)
ignoring the certbot thing, I'd bet the scammers are going to be all over these 6 day certs. They tend to register a random ~12 character domain name for their payload server, knowing its going to be entered into all the RBLs within a few hours and will need to generate a new random name and re-register. This will just lower their operating costs a little.
Re: (Score:2)
How is it lowering their operating costs? A 90-day LE certificate costs $0.00, as opposed to a 6-day certificate that costs $0.00...
Let's encrypt is getting defunded? (Score:1)
DOGE. Can't remember the name of the parent fund. I don't believe it's all the funding, but could be enough to tank it?
Wrong direction. (Score:2)
Just give us 10 year certs back. There's no reason for this nonsense.
Re: (Score:2)
For generic internet facing systems, there's so many potential key compromises and we've realized by now that there's no sane approach to revocation, at least no scalable approach. So "effectively immortal" certificates create an untenable situation where a key compromise gives an attacker years of potential to use that material.
Besides, long lived certificates have really bitten a lot of big providers. When expiration finally does happen, they hadn't been bothering to look out for an issue and even when th
Do Not Fucking Want! (Score:2)
I don't fucking ever want to have to deal with 6 day certs.
There are lots of things that cannot have automated cert renewals. There are many systems that need to be prevented form accessing the internet and will never have automated renewal. 12 month maximum certs are bad enough. Anything less is misery.