Forgot your password?
Close
typodupeerror
Encryption

Let's Encrypt to Cut SSL Certificate Lifetimes to 64 Days in February 2027 (linuxiac.com) 116

Posted by EditorDavid from the seeking-security dept.
Let's Encrypt "will shorten the default validity period of its TLS certificates from 90 days to 64 days, starting February 10, 2027," reports the blog Linuxiac: All certificates issued or renewed from that date will have a 64-day lifespan unless users explicitly select one of the shorter options already available: 45 or six days.

Existing certificates will remain valid until their expiration dates. Let's Encrypt expects the final 90-day certificate to expire on May 11, 2027. The organization also confirmed no valid certificates will be revoked during the transition. To help administrators prepare, Let's Encrypt will introduce 64-day certificates in its staging environment on October 14, 2026, allowing users to test their renewal setups before the change reaches production.

The move is part of a broader effort to improve web security by reducing how long compromised or incorrectly issued certificates remain usable... Looking further ahead, the organization plans to reduce the default certificate lifetime again, this time to 45 days in 2028. That makes the upcoming 64-day limit an intermediate step rather than the final destination.
"Administrators using cron jobs or scripts with hardcoded renewal intervals should review their configurations," the article suggests.

"Another upcoming change concerns domain validation. Let's Encrypt will reduce the period during which a previously completed domain authorization can be reused from 30 days to 10 days. In 2028, that period will shrink further to just seven hours."

Let's Encrypt to Cut SSL Certificate Lifetimes to 64 Days in February 2027 More | Reply

Let's Encrypt to Cut SSL Certificate Lifetimes to 64 Days in February 2027

Comments Filter:

  • Shrinkflation (Score:1)

    by Anonymous Coward
    Someone needs to submit this to r/shrinkflation and start a viral campaign against this!

  • and in more locked down env this will lead to something failing.

  • Very Annoying (Score:3, Insightful)

    by Baron_Yam ( 643147 ) on Monday October 12, 2026 @12:03AM (#66371662)

    Let's Encrypt's mission was to get everyone to use SSL... OK. Nice. Thank you.

    But now it's "We're reducing the validity window to force you to use automation by making manual updating more frequent than people will tolerate". What the hell is so bad about manual updates?

    There's a whole world of people out there who are too small to set up a nice automated system but who still should be using SSL, and this is Let's Encrypt telling us they don't really believe in their mission statement.

    • Sounds like theres a need for an easy automation solution.

      • Re: Very Annoying (Score:5, Interesting)

        by tlhIngan ( 30335 ) <slashdot@w o r f . net> on Monday October 12, 2026 @01:50AM (#66371738)

        Sounds like theres a need for an easy automation solution.

        The problem isn't the automation, it's when the automation fails. Do you remember how to fix the certificate manually? Or do you rely on the automated tool to never fail, and it just did?

        It's easy if it's regularly practiced or someone documented the steps, but it's rarely going to be practiced (likely forgotten if the automation works for years) and documentation gets lost. It might be in a great spot in the IT wiki and IT documentation, but that gets forgotten about as platforms migrate. People also leave.

        Suddenly, the automation fails. Maybe it got a bad certificate from the CA. Or maybe a parameter changed that triggered some unforseen bug in the automation. or an update was run that had a bug when used in the environment. Now it fails. And you're screwed, because no one knows how to fix it.

        Automation works, until it doesn't. Then things that were relying on it break. Maybe you're lucky and you catch things breaking early to realize what is happening. But chances are, one day you'll try to log in, and you'll get a big "Certificate Expired" screen on the browser and suddenly your VM clusters are inaccessible because they don't have valid certs (seen this happen with openvirt) and the company is at a standstill becauze nothing works.

        The danger of automation isn't when it works. It's when it doesn't and no human has touched the system in years because of it and tribal knowledge has dissipated in the winds, documentation is lost, and no one remembers how the system worked.

        • You need people who know how x509s work. You need people who understand how your devices work. Automation doesn't replace the need for expertise. It only lets those people get more out of their time.

          • Re: Very Annoying (Score:5, Insightful)

            by _merlin ( 160982 ) on Monday October 12, 2026 @05:16AM (#66371888) Homepage Journal

            The trouble with really short expiries is you have a lot less time to fix issues before everything breaks. With 90 day expiries, you can comfortably renew your certificates two weeks before expiry, giving you plenty of time to sort out any issues before things break. With the 7-day expiries they're pushing for, you've got almost no time between scheduled renewal and certificate expiry to get stuff sorted out when things inevitably go wrong. The point of the really short expiries seems to be to compensate for revocation being under-utilised or something. But are there any real-world issues with 90-day certificates? Also, I really don't trust the certbot scripts very much. It's a lot of code I don't trust to allow running as root if I want to allow automated scripted renewal. Right now I run certbot as an unprivileged user and manually install the updated certificates and bounce services. That's going to become impractical as they make expiries shorter. And that's before you consider all the devices that don't make automation practical. Lots of devices have embedded servers.

            • In the most extreme case you could get a new client cert for every single connection. In fact, that really doesn't seem that difficult.

            • If you have many things that need certificates, why aren't you getting a wildcard certificate centrally, and making it available where it's needed?

              Now you have one thing to look after, and drop-dead reliable file sharing with well understood permissions and security for distribution.

              Don't make this harder than it needs to be.

          • The mission is to get everyone on SSL, that's going to include people without a clue

          • Re: (Score:2)

            by pla ( 258480 )
            Sure, we'll just assign "master all things x509" to engineer #78 of 205... in our four-person shop.

            Everyone in this conversation seems to be assuming every company has a massive IT department with folks just standing around picking their noses waiting for real work to show up and break the monotony. Outside Silicon Valley and Fortune-500s, that's an extreme rarity.

            There's also an implicit assumption we're all running major-vendor enterprise-grade software written within the last twenty years; rather tha

            • Sure, we'll just assign "master all things x509" to engineer #78 of 205... in our four-person shop.

              You can't. You won't. You will outsource all of that to your web provider. Mine handles renewing my cert for me automatically. I could provide my own, but I don't have to. Instead, they handle getting it... from Let's Encrypt. I will not even notice this change, because they will continue to do so.

              I have done my own self-signed certs and whatnot, I have installed certs from Verisign professionally yada yada, but there's no reason for me to do anything other than this for my vanity site. But there's really n

            • You either need a turnkey solution you can buy or you need someone who can do proper security for something you build. Shrugging off security because your homebrew thing never had it before isn't the right answer.

            • You are making this way harder than it is.

              I have literally everything on my home network that has the CPU grunt to perform HTTPS, doing HTTPS using LetsEncrypt. If it's in Kubernetes, use cert-manager and automatically issue / renew certs based on the hostname in your ingress. If it's not, have a cron job that gets a wildcard cert, and put it on a fileshare for things that need it.

              This maybe takes an hour to set up and only think about if you get an email that a certificate renewal failed, which I have ye

        • Re: (Score:2)

          by allo ( 1728082 )

          You shouldn't fix the certificate. You should fix the automation. That's their whole point, the best certificate has a short lifetime and is renewed soon.

        • The truth is that we depend on many components that can fail at any time and that most of us will have no clue how to fix. Your are focusing on one, while apparently taking the reliability of the others for granted. Yes, your certificate renewal automation can fail, but so can your computer, modem, router, power, etc. That's life.

      • There is, look up the ARI - ACME Renewal Information, https://www.rfc-editor.org/rfc/rfc9773.html

      • Sounds like theres a need for an easy automation solution.

        Well, Letsencrypt's framework looks daunting to the uninitiated, but the truth is that anything to do with this type of certificates does anyway, by their own nature. I set up mine a while ago, with safeguards to notify in case of failure, for three separate Linux systems driven from a single one, and it was not that complicated. Granted, I am more experienced than the average Joe, but we are talking Bash scripts twenty lines long or so, not convoluted stuff using lots of different files, libraries and what

    • Re:Very Annoying (Score:5, Interesting)

      by SoonerPet ( 893902 ) on Monday October 12, 2026 @12:59AM (#66371700)
      Our problem is we have several systems that use SSL for internal network authentication, but there is no way to automate them. We have phone system hardware that requires an SSL cert to communicate with the handsets around the office, but we have to go into a web interface on it to copy and paste the cert each year. We have the same thing for an internal camera/security system, same thing for a badge system. All of these things are local, not on the internet, yet require SSL certs for internal authentication with clients, and no way to automate these as they are just stand alone devices. As it is it’s a pain in the ass to update them, but if we have to do this on a monthly basis it’s just absurd.
      • Implement a private PKI, you're already doing most of the work.

      • Re: (Score:2)

        by tlhIngan ( 30335 )

        Our problem is we have several systems that use SSL for internal network authentication, but there is no way to automate them. We have phone system hardware that requires an SSL cert to communicate with the handsets around the office, but we have to go into a web interface on it to copy and paste the cert each year. We have the same thing for an internal camera/security system, same thing for a badge system. All of these things are local, not on the internet, yet require SSL certs for internal authenticatio

        • They said it was a web interface and are local and not internet connected. Probably a proprietary interface that wouldn't be safe to connect to the internet anyway.

          • In which case, create your own root with an open source tool like CFSSL, use that root to sign a nice long-lived certificate (say, 10 years), and then import the root as trusted on the devices as well as your long-lived cert. Then you don't even need to do it annually any more.

            • use that root to sign a nice long-lived certificate (say, 10 years)

              Apple caps that at 825 days. That's still a somewhat long time, but they can shorten it whenever they feel like it. And I fully expect them to do that sometime after the 47-day max for public CAs becomes normalized.

              • You can trust your own certificates in an Apple Keychain. This is clearly an enterprise of some kind - if they are using Apple devices, and not using device management when Apple makes this unbelievably easy, then they get the runaround.

            • In a business environment that could add a lot of cost. Probably nobody has experience doing that, and you're going to have to ensure it is documented well enough that a new employee who has never done it before can take it over (potentially during a crisis where you just found out there's a problem with it)

              • In a business environment sufficiently scaled to need the equipment the guy is talking about, if you don't have someone that understands TLS in 2026, you have bigger risks than anything you just mentioned.

      • Re: (Score:2)

        by AmiMoJo ( 196126 )

        If it is for local use only you can just make your own certificates, and set yourself up as the authority if needed. If these devices allow you to upload a certificate then they really should support that, because otherwise their list of certificate authorities will go stale quickly and they will stop working.

      • If you are updating through a web interface then it absolutely can be automated, you need to sack your IT staff if they told you that wasn't possible.

      • You probably need an internal CA to issue you with certs. If you're not on the Internet, this is probably your best bet - but it's a bit of a hassle. I'm slightly amazed you can't buy a "CA Appliance" to do this sort of thing for you (or maybe you can, and I didn't notice?).

        Alternatively, you might be able to use wildcard certs (or not, depends on your security requirements). If you can, then you could centrally get the certs issued, and store them in a cloud bucket or a network drive or something. You'd th

      • If they are not on the public Internet, and not talking to a web browser with it's own trust store, you don't need to give a shit.

        Implement your own PKI, have these devices trust your root, and issue a 100 year certificate signed by that root.

        LetsEncrypt is in the business of issuing publicly trusted certificates. If you don't need their trusted root to sign it, don't.

      • Here is the 'word' that you need: SCEP

        That is all.

    • I don't think lets encrypt was ever a good solution for equipment you can't automate. You can still get 3yrs and probably even 6yrs certs from some singing authorities if you want longer lasting certificates. But then people will say that's too long. Lol

    • Re: (Score:3)

      by Kisai ( 213879 )

      Google and Let's Encrypt has basically destroyed the web. What was once a way to ensure people were paying attention to what site they were entering their credit card details on, has turned into a way to undermine the privacy of everyone by allowing parties who don't actually care about security, roll out flawed after flawed solution. Look no further than "rogue AI" slop we've been seeing.

      These AI's don't care about privacy or your server's capacity for bandwidth or processing power, they just access every

      • But oh no, the SSL has to protect everything, so now what used to be a server that could server 10,000 users simultaneously, is now reduced to about 50, because SSL makes it impossible to generate static content. And the AI's have figured out that if they can access a resource without SSL they can throw 200x more traffic at it. So much for the "ew a non-SSL site" message google chromium-related browsers give. The AI's do not care.

        This is laughably stupid.

        What about SSL / TLS do you think "makes it impossible to generate static content" whatever that's supposed to mean?

        You do know that entire Linux distro mirrors (static content) are served using HTTPS from Amazon S3, yeah? For pennies?

        You know how CDNs work, using HTTPS, serving static content? Like, literally millions of sites?

        There is absolutely nothing about SSL / TLS that prevents what you are talking about doing, or gives any of the problems you are talking about, if you knew

    • The browser / certificate industry as a whole has ignored the issue of cert revocation because "it slows things down". That's the entire problem on the technical side, but there's a financial side most ignore. They want certs that aren't valid for as long, so if you follow that argument what they are moving to is certs that are only valid for a very short time like days or hours, so they don't need revocation. The fact that this forces out smaller players "who are too small to set up a nice automated system

    • One shop I worked at we only got certs for 7 days - that was a bit nasty, you had to have really good automation, and really good monitoring (and remediation). Quite often we'd have the server update its certs, but (say) nginx would fail to reload to pick them up. It definitely requires a higher level of engineering. I'd expect the same is true for 90 days coming down to 64, but probably not quite so pronounced.

      I believe the thinking about days is to do with security. The problem is that an attacker might g

    • Actually, I suspect this is part of the continuing effort to drive individuals to use hosting services, offloading the management to a vendor, no matter how cheap. Us hobbyists are a thorn in the side of Internet security, where making a small, seemingly insignificant mistake, leads to your host being a trampoline sending nasty security threats all over the world.

      The Internet is still at risk of becoming the even-more-exclusive domain of the corporations. While I worry that RS is a bit too vigilante, truth

      • It also allows your favorite bogeyman (Government, Deep State, Facist Regime, whatever floats your boat) to knock a site off the internet faster. Poof, this domain is blacklisted, can't renew SSL... now the site looks like a black sheep to ... uh... the sheep.

        I'm sure there will be no abuse.

    • But now it's "We're reducing the validity window to force you to use automation by making manual updating more frequent than people will tolerate". What the hell is so bad about manual updates?

      Seems like herding cattle. I'm just waiting for more incompatible changes and deal altering to drop at any time at which point everyone is completely fucked with a few days to react.

      Manual intervention to update certs is likely being replaced with manual intervention to deal with breakage of automation software... automation software that is itself a vector for compromise.

      There's a whole world of people out there who are too small to set up a nice automated system but who still should be using SSL, and this is Let's Encrypt telling us they don't really believe in their mission statement.

      I hate everything about this house of cards. A few people deciding for the world, global fully overlapping trust anchors, everything be

    • Certbot is just not that hard. You either make an endpoint available to it for HTTP, or you give it credentials to create a TXT record in DNS to confirm you are who you say you are. Then you set up a cron job.

      This has been, and still is, well documented. If it makes people learn how to use the system properly, we all end up in a better place.

      Time to start "doing it right" and stop bitching about being forced to do it right.

      • And this doesn't work if your DNS provider doesn't have a plugin and you've got multiple servers behind a single host name.

        Certbot sucks. And it's particularly annoying to hear people make grand claims about its efficacy without realizing they only represent a tiny fraction of people for whom the software has been designed.

        Essentially, they pushed all the hobbyists onto these low life certs to get everyone to pay more money for long lived certs. Because now small businesses have to be on these dying certs,

  • It is the CA/B recommendations (Score:5, Informative)

    by CommunityMember ( 6662188 ) on Monday October 12, 2026 @12:25AM (#66371674)
    Of course what is ignored by many is that CA/B Forum has codified the changes to reduced lifetimes (49 days by 2029). Letsencrypt is just preparing for the hard limits sooner than some others (but the others should be there soon now).

    • So it's the right hand telling the left hand what to do. To spell it out: The "CA/B Forum" is "The Certification Authority Browser Forum (CA/Browser Forum) is a voluntary gathering of Certificate Issuers and suppliers of Internet browser software and other applications that use certificates (Certificate Consumers)." Letsencrypt is one of the members.

      • Re: (Score:2)

        by _merlin ( 160982 )

        We really need an alternative to Let's Encrypt to put an end to this bullshit.

        • ZeroSSL is a viable alternative. Google offers free certificates as well.

          But the bullshit, as you say, is being driven and forced by the browsers and companies like Apple. A 3 year certificate lifetime isn't useful when clients won't accept anything longer than 47 days.

  • Maybe I'm missing something here, but, couldn't they satisfy "reducing how long compromised or incorrectly issued certificates remain usable" by revoking the ones which are found to have been compromised? That data gets collected somewhere, right.

    Isn't automatic renewal less than that with ACME automation, anyway? And how does ACME just 'go away' on systems which have been compromised?

    • Certificate Revocation Lists are a thing, yes. However, you still need automation to push them anyway. And if your root private key is compromised, then CRLs won't save you. It's better to rotate regularly so that when the compromise happens, you don't have to figure everything out for the first time.
      • If your Root private key is compromised this process won't save you either. This has ZERO impact on root certs which should remain at multiple years and the private key ideally kept offline except when you need to sign a new intermediate issuing cert.

    • Re: (Score:2)

      by raynet ( 51803 )

      The revocation system doesn't really scale enough which is one reason they want to limit certification timespans. Other is security holes which cannot get patched if certs are valid too long.

      • Re: (Score:2)

        by deKernel ( 65640 )

        So then the revocation system should be addressed and not simply trying to apply a band-aid which this really is. The mathematics behind the certs is solid meaning they can go for extended periods without successful attacks.

  • Not short enough (Score:5, Funny)

    by backslashdot ( 95548 ) on Monday October 12, 2026 @01:23AM (#66371718)

    64 seconds ought to be good for anybody. Especially if the website is running node JS the certificate can expire midway during library download.

  • Those of you who have to handle this as part of your job: how are you guys planning to deal with devices where automation does not appear to be possible? Older multifunction printers, for example?

    • Re: (Score:1)

      by Haegar ( 1160 )

      For non externally visible systems we more and more just say "f*ck it" and just let the certs expire, and every (internal) user has to click through the browser warnings.

    • Internal CAs

    • Easy - dump it and buy some new toys.

      Once the cert expires, claim it's 'broken', spend a bit too long fixing it, and tell them it's only a temporary patch up, it'll fail again - then let it fail again. Rinse, repeat and wait for the sign-off to buy something new.

      Honestly, old crap hardware might look cheap, but it really isn't. Either it gets a software update, or it gets donated. Security isn't really something you can cheap out on (even if you're only a small shop).

      Side-story: We have an old laser printer

    • With an internal-only CA we manage ourselves

    • Re: (Score:2)

      by darkain ( 749283 )

      Automation is possible everywhere. Even if its a generic web form w/ a file upload button? Yeah, I've got a couple of those in my environment. There is a script that simulates the login steps and then does the "upload" POST request.

    • Re: (Score:2)

      by EvilSS ( 557649 )
      There's this new thing called an internal CA where you can issue your own certs with whatever expiration date you feel like.

      • Frankly, I posted my question in hopes that some bright boy had come up with a better approach than setting up (and managing) our own CA.

        • Re: (Score:2)

          by EvilSS ( 557649 )
          Sorry but that is the answer, it's what internal CAs are for. If the devices truly do not support automation, and you need certs for them (do you really need them if this is a home or small office network?) then your choice is use public certs and live with the ever-shorter expiration requirements or put up your own CA.

  • DANE or GTFO (Score:5, Informative)

    by Arnonyrnous Covvard ( 7286638 ) on Monday October 12, 2026 @04:05AM (#66371838)

    All browser makers are united against DANE [wikipedia.org], because supporting it would dismantle their certificate gatekeeping. Instead they keep lowering the maximum certificate lifetime to make sure that nobody can host a web page unless they check in with them every few weeks.

    • Re: (Score:3)

      by allo ( 1728082 )

      Using DANE means your DNS registrar can impersonate you. They can even do so selectively by faking the record only on some connections, e.g. based on GeoIP. CAs mean the browser needs to have a not trustworthy root CA shipped with it. Certificate transparency means, that browsers only accept certificates that were published to be used and site owners can find any additional certificates published by an attacker who wants to intercept connections. DANE is a nice idea, but makes the DNSSEC record the master k

      • Re: (Score:2)

        by MeNeXT ( 200840 )

        DNS registrar? I don't follow. Do you have a registrar for your DNS provider or are you talking about your Domain Name registrar?

        In either case the entity that has control of a domain can issue certificates for the Domain. Meaning your domain registrar can issue certificates with every cert provider if they are evil. Doesn't make a difference what/who the registrar is, you or central.

        • Re: (Score:2)

          by allo ( 1728082 )

          You're right, that domain verified certificates generally have this problem. But CAs have to append the certificates to the transparency log, so overtaking your domain and requesting a certificate cannot be done secretly. That's the whole point to the CT log otherwise this would be indeed a dangerous attack vector.

          • Re: (Score:2)

            by MeNeXT ( 200840 )

            I don't see how it can be done secretly with DNSSEC either. A trace will be left behind no matter what. This is not to say that either method is foolproof but when laws are interpreted and major news outlets are scared of their own government what makes you think that a CT log will be effective?

            • Re: (Score:2)

              by allo ( 1728082 )

              I don't see the trace with DNSSEC. Let's say your DNS hoster generates a key and signs it for your domain. Now they see a request from a certain IP range and show signed records with their key, with a valid certificate chain to the registrar key (and from there up to the root keys). Other people see records signed by your key, which is also verified by the registrar and correct. Other than the CA system there is no public record of all keys, but the DNS provider can generate and sign secretly as many as the

    • Re: (Score:2)

      by Takeel ( 155086 )

      This is naturally better done with a hosts file. :)

      • Anyone else remember the days where Slashdot's biggest complaint was APK and not bitching about my-side vs your-side, on political disaster du jour?

    • Re: (Score:2)

      by Tom ( 822 )

      Without buying into the conspiracy theory, but this is why I dislike these short lifetimes. It makes my otherwise 100% autonomous website dependent on an external party. I think I'll go back to also offer the site on unencrypted http instead of making an https redirect.

  • All of our system configurations are under revision control. Before any revision can be committed, it must be reviewed by someone other than the person who wants to make the commit. (I trust this kind of process is familiar to everyone. It's designed to at least partially mitigate the problem that most people won't see their own mistakes even if they're diligent about looking for them.) Once a revision is committed (and thus checked into the revision control system and subsequently deployed in the live
    • Proper automation means you shouldn't need these manual approval steps. Repeatable automated tasks with good error handling shouldn't require it. Adequately test your automations, and ensure they are running across all environments, not just production.

      • Re: (Score:2)

        by PPH ( 736903 )

        Until

        • -Your automation runs into an edge case.
        • - AI has entered the conversation.
        • You can run into an edge case doing this manually. If your automatic runs into some edge case, you update the automation to handle it. Next time they happens, all is good. No much much with humans doing to work.

          • Re: (Score:2)

            by PPH ( 736903 )

            You can run into an edge case doing this manually.

            Yes. But then you're there to fix it. Test the production install first, of course. I've had a few cases where I pushed something out, checked it, found a problem and reverted the change before the users ever noticed.

  • Why does it seem like the security crowd is losing the battle?

    It took forever to figure out that requiring too frequent of password changes resulted in people writing their password right on their monitor with a sticky note.

    - moooaar slop! faster! slop! slop! slop!

    • It took forever to figure out that requiring too frequent of password changes resulted in people writing their password right on their monitor with a sticky note.

      What's the analog to this in the certificate world? I can see how a short cert expiry is a PITA to manage in some deployments, but not how it's likely to lead to less secure behavior.

      • I can see how a short cert expiry is a PITA to manage in some deployments, but not how it's likely to lead to less secure behavior.

        More hardcoded passwords and the like in the renewal processes where people have been doing them manually and don't know how to automate them correctly. These people should be outsourcing this...

        • Re: (Score:2)

          by PPH ( 736903 )

          These people should be outsourcing this...

          Of course. It's the Dunning-Kruger system admins that need to take down thier roll-your-own sites. And move them all over to AWS.

          Guess who runs port scans/penetration tests in my neighborhood?

  • When will it stop being called a SSL cert? There has never been nor will there ever be a SSL cert. A; it's a x.509 certificate and B; no one uses SSL anymore, it's TLS

  • It sounds like they are assuming that all certs are compromised, thus undermining the whole point of having a cert.

    • Re: (Score:2)

      by PPH ( 736903 )

      Well, this.

      Since it is _possible_ to compromise a certificate* but then revoke and replace it, why not just do that?

      *Often within hours or even minutes. What? Did you not think that hackerz can wrap exploits in cron job scripts?

  • Horribly insecure! (Score:3)

    by CEC-P ( 10248912 ) on Monday October 12, 2026 @09:41AM (#66372196)
    If you implement a certificate incorrectly the first time, you'll do it wrong the second time. So there goes argument number 1. Nobody is brute forcing these in even a year so there's argument number 2. Every time you generate, download, and install, then store a certificate, that's a chance for it to get intercepted. And you know some dumbass is putting it out on a server in a random folder or uploading it to OneDrive by putting it on their desktop. Or they have a browser plugin that can spy on downloads. This is idiotic and they're going to lose all their customers.

  • I have a wildcard cert from LetsEncrypt and it renews itself automatically and gets distributed to all the machines that need it, also automatically.

    I also have a system monitoring my certificates that warns me if they're about to expire in less than 21 days (which should never happen unless the automation has been broken.)

    For my OpenVPN certificates, I set up my own CA and created certs that expire in 2044. Since my OpenVPN infrastructure is completely private, that's perfectly acceptable. And I can qu

  • The truth is even the strongest brute force cannot break a cert within few years. It would be easy to steal the key and its passphrase via social engineering. The cert providers make only a few hundred/year each cert so they influenced the entire security world about how a cert length can jeopardize things. In each operation there can be hundreds to thousands of certs. Rapidly reducing their lengths from 5-3-2-1 down to 9-6-3-1 months is their exact roadmap to more money.
  • I have a wildcard cert from LetsEncrypt, which I install on all the services on my home LAN. However, because it's a wildcard, LetsEncrypt insists that I prove domain ownership by updating some DNS TXT records. My DNS provider doesn't support automated updates to TXT records. So ACME won't work, so I have to do that bit by hand.

    Next, I have to distribute the cert to a handful of local services, including pfSense, TrueNAS, Postfix, the Unifi Controller (extra annoying, because Java), Forgejo, and probab

  • outside of CA's or cert user mistakes... is there a known incident where an SSL was actually compromised?

    I know of many cases where the CA's messed up... or a company made the private key public... but i can't find/recall a single case where an SSL was actually compromised.

    IS this an actuall issue?

  • Have they found a solution to the problem where a rouge CA (e.g. one controlled by a bad actor nation-state) can generate a bogus certificate for a major site and use that to man-in-the-middle traffic to that site?

  • Their servers go down because they DDOS themselves demanding more cert renewals than they can support. The blog certificates expire and browsers refuse to load your cat memes.

  • This is quite stupendous in administration.

Slashdot Top Deals

Don't sweat it -- it's only ones and zeros. -- P. Skelly

Close