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.

  • nialv7@lemmy.worldEnglish
    18·
    5 hours ago

    I’m sorry but if you aren’t using automated renewals then you are not using let’s encrypt the way it’s intended to be used. You should take this as an opportunity to get that set up.

    • bss03@infosec.pubEnglish
      1·
      9 minutes ago

      Technically my renews aren’t automated. I have a nightly cronjob that should renew certificates and restart services, but when the certificates need renewal, it always fails because it wants to open a port I’m already using in order to answer the challenge.

      I hear there’s an apache module / configuration I can use, but I never got around to setting it up. So, when the cron job fails, I get an email and go run a script that stops apache, renews certs, and restarts services (including apache). I will be a bit annoying to have to do that more often, but maybe it’ll help motivate me to configure apache (or whatever) correctly.

      Debian Stable

    • merc@sh.itjust.worksEnglish
      1·
      26 minutes ago

      I’m using automated renewals.

      But, that just means there’s a new cert file on disk. Now I have to convince a half a dozen different apps to properly reload that changed cert. That means fighting with Systemd. So Systemd has won the first few skirmishes, and I haven’t had the time or energy to counterattack. Now instead of having to manually poke at it 4x per year, it’s going to be closer to once a month. Ugh.

      • NotMyOldRedditName@lemmy.worldEnglish
        11·
        21 minutes ago

        Don’t worry, they’ll sell you new software for another $50.00/m/certificate to help with the new certificate fiddling you now have to do monthly. It didn’t make sense for them to release it until they pushed through the 45 day window change through backchannels.

    • Zanathos@lemmy.worldEnglish
      1·
      4 hours ago

      While I agree for my personal use, it’s not so easy in an enterprise environment. I’m currently working to get services migrated OFF my servers that utilize public certificates to avoid the headache of manual intervention every 45 days.

      While this is possible for servers and services I manage, it’s not so easy for other software stacks we have in our environment. Thankfully I don’t manage them, but I’m sure I’ll be pulled into them at some point or another to help figure out the best path forward.

      The easy path is obviously a load balanced front-end to load the certificate, but many of these services are specialized and have very elaborate ways to bind certificates to services outside of IIS or Apache, which would need to trust the newly issued load balancer CA certificate every 47 days.