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.

  • jj4211@lemmy.world
    link
    fedilink
    English
    arrow-up
    11
    arrow-down
    1
    ·
    2 days ago

    Ours is automated, but we incur downtime on the renewal because our org forbids plain http so we have to do TLS-ALPN-01. It is a short downtime. I wish let’s encrypt would just allow http challenges over https while skipping the cert validation. It’s nuts that we have to meaningfully reply over 80…

    Though I also think it’s nuts that we aren’t allowed to even send a redirect over 80…

    • Atemu@lemmy.ml
      link
      fedilink
      English
      arrow-up
      1
      ·
      5 hours ago

      Forgive my ignorance but why would that incur a downtime?

      The only way I can think of for downtime to happen if you switched certs before the new one was signed (in which case …don’t) or am I missing something?

      It also strikes me as weird that LE requires 80 but does allow insecure 443 after a redirect. Why not just do/allow insecure 443 in the first place?

      • jj4211@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        4 hours ago

        the TLS-ALPN-01 challenge requires a https server that implements generating a self-signed certificate on demand in response to a specific request. So we have to shut down our usual traffic forwarder and let an ACME implementation control the port for a minute or so. It’s not a long downtime, but irritatingly awkward to do and can disrupt some traffic on our site that has clients from every timezone so there’s no universal ‘3 in the morning’ time, and even then our service is used as part of other clients ‘3 in the morning’ maintenance windows… Folks can generally take a blip in the provider but don’t like that we generate a blip in those logs if they connect at just the wrong minute in a month…

        As to why not support going straight to 443, don’t know why not. I know they did TLS-ALPN-01 to keep it purely as TLS extensions to stay out of the URL space of services which had value to some that liked being able to fully handle it in TLS termination which frequently is nothing but a reverse proxy and so in principle has no business messing with payload like HTTP-01 requires. However for nginx at least this is awkward as nginx doesn’t support it.

    • kungen@feddit.nu
      link
      fedilink
      English
      arrow-up
      12
      ·
      2 days ago

      Hot take: for-profit orgs should be buying TLS certificates from the CA cartel instead of using Let’s Encrypt. Unless you’re donating to LE, and in that case it’s cool.

      • jj4211@lemmy.world
        link
        fedilink
        English
        arrow-up
        2
        ·
        1 day ago

        Frankly, another choice virtually forced by the broader IT.

        If the broader IT either provides or brokers a service, we are not allowed to independently spend money and must go through them.

        Fine, they will broker commercial certificates, so just do that, right? Well, to renew a certificate, we have to open a ticket and attach our csr as well as a “business justification” and our dept incurs a hundred dollar internal charge for opening that ticket at all. Then they will let it sit for a day or two until one of their techs can get to it. Then we are likely to get feedback about something like their policy changing to forbid EC keys and we must do RSA instead, or vice versa because someone changed their mind. They may email an unexpected manager for confirmation in accordance to some new review process they implemented. Then, eventually, their tech manually renews it with a provider and attaches the certificate to the ticket.

        It’s pretty much a loophole that we can use let’s encrypt because they don’t charge and technically the restrictions only come in when purchasing is involved. There was a security guy raising hell that some of our sites used that “insecure” let’s encrypt and demanding standards change to explicitly ban them, but the bearaucracy to do that was insurmountable so we continue.

    • nialv7@lemmy.world
      link
      fedilink
      English
      arrow-up
      6
      ·
      2 days ago

      our org forbids plain http

      is redirecting http to https also out of the question? because let’s encrypt HTTP-01 accepts http -> https redirects:

      Our implementation of the HTTP-01 challenge follows redirects, up to 10 redirects deep. It only accepts redirects to “http:” or “https:”, and only to ports 80 or 443. It does not accept redirects to IP addresses. When redirected to an HTTPS URL, it does not validate certificates.

      • jj4211@lemmy.world
        link
        fedilink
        English
        arrow-up
        2
        ·
        2 days ago

        They in fact refuse to even do a redirect… it’s monumentally stupid and I’ve repeatedly complained, but ‘security’ team says port 80 doing anything but dropping the packet or connection refused is bad…