Let’s Encrypt will be reducing the validity period of the certificates we issue. We currently issue certificates valid for 90 days, which will be cut in half to 45 days by 2028. This change is being made along with the rest of the industry, as required by the CA/Browser Forum Baseline Requirements, which set the technical requirements that we must follow. All publicly-trusted Certificate Authorities like Let’s Encrypt will be making similar changes. Reducing how long certificates are valid for helps improve the security of the internet, by limiting the scope of compromise, and making certificate revocation technologies more efficient.

Let’s Encrypt will be reducing the validity period of the certificates we issue. We currently issue certificates valid for 90 days, which will be cut in half to 45 days by 2028.
This change is being made along with the rest of the industry, as required by the CA/Browser Forum Baseline Requirements, which set the technical requirements that we must follow. All publicly-trusted Certificate Authorities like Let’s Encrypt will be making similar changes. Reducing how long certificates are valid for helps improve the security of the internet, by limiting the scope of compromise, and making certificate revocation technologies more efficient.

  • Arghblarg@lemmy.caEnglish
    438·
    5 hours ago

    So what’s the floor here realistically, are they going to lower it to 30 days, then 14, then 2, then 1? Will we need to log in every morning and expect to refresh every damn site cert we connect to soon?

    It is ignoring the elephant in the room – the central root CA system. What if that is ever compromised?

    Certificate pinning was a good idea IMO, giving end-users control over trust without these top-down mandated cert update schedules. Don’t get me wrong, LetsEncrypt has done and is doing a great service within the current infrastructure we have, but …

    I kind of wish we could just partition the entire internet into the current “commercial public internet” and a new (old, redux) “hobbyist private internet” where we didn’t have to assume every single god-damned connection was a hostile entity. I miss the comraderie, the shared vibe, the trust. Yeah I’m old.

    • atzanteol@sh.itjust.worksEnglish
      452·
      4 hours ago

      Will we need to log in every morning and expect to refresh every damn site cert we connect to soon?

      Automate your certificate renewals. You should be automating updates for security anyway.

      • dan@upvote.auEnglish
        171·
        4 hours ago

        This is one of the reasons they’re reducing the validity - to try and convince people to automate the renewal process.

        That and there’s issues with the current revocation process (for incorrectly issued certificates, or certificates where the private key was leaked or stored insecurely), and the most effective way to reduce the risk is to reduce how long any one certificate can be valid for.

        A leaked key is far less useful if it’s only valid or 47 days from issuance, compared to three years. (note that the max duration was reduced from 3 years to 398 days earlier this year).

        From https://www.digicert.com/blog/tls-certificate-lifetimes-will-officially-reduce-to-47-days:

        In the ballot, Apple makes many arguments in favor of the moves, one of which is most worth calling out. They state that the CA/B Forum has been telling the world for years, by steadily shortening maximum lifetimes, that automation is essentially mandatory for effective certificate lifecycle management.

        The ballot argues that shorter lifetimes are necessary for many reasons, the most prominent being this: The information in certificates is becoming steadily less trustworthy over time, a problem that can only be mitigated by frequently revalidating the information.

        The ballot also argues that the revocation system using CRLs and OCSP is unreliable. Indeed, browsers often ignore these features. The ballot has a long section on the failings of the certificate revocation system. Shorter lifetimes mitigate the effects of using potentially revoked certificates. In 2023, CA/B Forum took this philosophy to another level by approving short-lived certificates, which expire within 7 days, and which do not require CRL or OCSP support.

    • JASN_DE@feddit.orgEnglish
      182·
      4 hours ago

      So what’s the floor here realistically, are they going to lower it to 30 days, then 14, then 2, then 1?

      LE is beta-testing a 7-day validity, IIRC.

      Will we need to log in every morning and expect to refresh every damn site cert we connect to soon?

      No, those are expected or even required to be automated.

    • cron@feddit.orgEnglish
      4·
      4 hours ago

      The best approach for securing our CA system is the “certificate transparency log”. All issued certificates must be stored in separate, public location. Browsers do not accept certificates that are not there.

      This makes it impossible for malicious actors to silently create certificates. They would leave traces.

      • False@lemmy.worldEnglish
        1·
        1 hour ago

        Isn’t this just CRL in reverse? And CRL sucks or we wouldn’t be having this discussion. Part of the point of cryptographically signing a cert is so you don’t have to do this if you trust the issuer.

        Cryptography already makes it infeasible for a malicious actor to create a fake cert. The much more common attack vector is having a legitimate cert’s private key compromised.

        • cron@feddit.orgEnglish
          1·
          47 minutes ago

          No, these are completely separate issues.

          • CRL: protect against certificates that have their private key compromised
          • CT: protect against incompetent or malicious Certificate Authorities.

          This is just one example why we have certificate transparency. Revocation wouldn’t be useful if it isn’t even known which certificates need revocation.

          The National Informatics Centre (NIC) of India, a subordinate CA of the Indian Controller of Certifying Authorities (India CCA), issues rogue certificates for Google and Yahoo domains. NIC claims that their issuance process was compromised and that only four certificates were misissued. However, Google is aware of misissued certificates not reported by NIC, so it can only be assumed that the scope of the breach is unknown.

          Source

        • Auli@lemmy.caEnglish
          1·
          52 minutes ago

          Or the more likely a rouge certificate authority giving out certs it shouldn’t.

        • cron@feddit.orgEnglish
          8·
          4 hours ago

          The only disadvantage I see is that all my personal subdomains (e.g. immich.name.com and jellyfin) are forever stored in a public location. I wouldn’t call it a privacy nightmare, yet it isn’t optimal.

          There are two workarounds:

          • do not use public certificates
          • use wildcard certificates only
          • Burnoutdv@feddit.orgEnglish
            12·
            3 hours ago

            But how to automate wildcard certificate generation? That requires a change of the txt record and namecheap for instance got no mechanism for that to automatically happen on cert bot action

    • dan@upvote.auEnglish
      4·
      4 hours ago

      The current plan is for the floor to be 47 days. https://www.digicert.com/blog/tls-certificate-lifetimes-will-officially-reduce-to-47-days, and this is not until 2029 in order to give people sufficient time to adjust. Of course, individual certificate authorities can choose to have lower validity periods than 47 days if they want to.

      Essentially, the goal is for everyone to automatically renew the certificates once per month, but include some buffer time in case of issues.

    • AlmightyDoorman@kbin.earth
      2·
      4 hours ago

      Not exactly what you mean because there are also bad actors but take a look at i2p, in some ways it feels like an retro internet.

    • slazer2au@lemmy.worldEnglish
      12·
      4 hours ago

      Seeing as most root CA are stored offline compromising a server turned off is not really possible.

      I’m more annoyed that I have 10 year old gear that doesn’t have automation for this.

      • Arghblarg@lemmy.caEnglish
        4·
        4 hours ago

        Oh, I’m really just pining for the days before the ‘Eternal September’, I suppose. We can’t go back, I know. :/