From today until March 15, 2026, the maximum lifetime for a TLS certificate is 398 days.

As of March 15, 2026, the maximum lifetime for a TLS certificate will be 200 days.

As of March 15, 2027, the maximum lifetime for a TLS certificate will be 100 days.

As of March 15, 2029, the maximum lifetime for a TLS certificate will be 47 days.

What’s everyone’s opinion on this? I think from a security standpoint their reasoning is valid and in many cases it’s very easy to automate the renewal with ACME or something else. But there’s likely gonna be legacy stuff still around in 2029 that won’t be easy to automate.

      • SecureTaco@lemmy.asc6.org
        link
        fedilink
        English
        arrow-up
        4
        arrow-down
        1
        ·
        4 days ago

        Self signed certs still have to abide. It’s the browser that checks it not the issuer. Now granted in most cases you already get a non trusted warning that most sysadmins skip…

        • Zeoic@lemmy.world
          link
          fedilink
          English
          arrow-up
          4
          ·
          4 days ago

          The cert is what tells the browser how long it lasts, so I’m not sure how the browser can stop you from using a 10 year self signed cert or one from your own CA

          • catloaf@lemm.ee
            link
            fedilink
            English
            arrow-up
            1
            ·
            4 days ago

            If the browser sees it expires too far in the future, it could throw a warning or error.

            I doubt any of them will actually do it, but it’s possible.

            • prime_number_314159@lemmy.world
              link
              fedilink
              arrow-up
              4
              ·
              3 days ago

              Most browsers do this for certs with a lifetime longer than 398 days issued after 2020, which is one aspect of why so many websites use a 1 year validity period for their certs.

    • Possibly linux@lemmy.zip
      link
      fedilink
      English
      arrow-up
      1
      ·
      3 days ago

      Self signed certs still support longer time frames

      If you need to expose a legacy system to the internet we have bigger issues

  • Admiral Patrick@dubvee.org
    link
    fedilink
    English
    arrow-up
    33
    ·
    edit-2
    5 days ago

    Are compromised private keys that much of a problem in the real world to merit such a pain in the ass, heavy handed “solution”? On paper, sure, it makes sense. In practice, you’re forcing people to complicate the process by introducing, until now, unnecessary automation and introducing the possibility of brand new points of vulnerability.

    I say this as someone who does maintain legacy systems (i.e. systems), so take it with a very angry, frazzled grain of salt. But I’ve done this for years decades and many, many systems and to my knowledge, I’ve never had a compromised private key.

    This just seems like people who constantly lose their house keys mandating that everyone else change their locks as often as they do.

    • bamboo@lemmy.blahaj.zone
      link
      fedilink
      English
      arrow-up
      9
      ·
      5 days ago

      One issue is that browsers and other clients have a difficult time handling certificate revocation. Let’s Encrypt is stopping support for OCSP, and that had a lot of privacy implications where a CA could tell who is going to what site, based on the requests to check certificate revocation. Let’s Encrypt is moving to CRLs, but the size of the CRL is very large the more certificates you have. For Let’s Encrypt with only a 90 day validity period, their CRL is smaller than a CA which has certificates as much as 398 days old.

      The size of the CRL is something not only CAs have to manage, on the client side, you may have to check a 10MB file to see if the certificate for the site you’re connecting to is still trusted by the CA. With many CAs, these CRLs will take up a lot of space on disk, and need to be updated often. Mozilla published a system called CRLite which uses Cascading Bloom Filters to keep track of revoked certificates in the browser, which will save a lot of space. Having a constrained set of revoked certificates is useful to ensure the bloomfilter won’t be too large for the browser to store and manage.

    • WhyJiffie@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      1
      ·
      3 days ago

      are you sure this mandates always using a new private key? I think I have read that they don’t. how would you verify that anyway?

    • JRaccoon@discuss.tchncs.deOP
      link
      fedilink
      English
      arrow-up
      2
      ·
      5 days ago

      I like that metaphor, I’m gonna save it. And agreed, there’s going to be issues with legacy systems.

      Luckily, at my current job, all of our outside-facing legacy services already go through an SSL terminating reverse proxy. And we then use self-signed certs with much longer validity for internal traffic where needed.

  • Z3k3@lemmy.world
    link
    fedilink
    English
    arrow-up
    6
    ·
    5 days ago

    My little corner of the business has started migrating our certs to let’s encrypt.

    Hope it catches on else where

    • Possibly linux@lemmy.zip
      link
      fedilink
      English
      arrow-up
      1
      ·
      3 days ago

      I am a little concerned about the fact that Let’s encrypt is a centralized service subject to outages. What would happen if they we either breached or had a several day issue.

      If you are in the cloud you can use the cloud provided certs

      • Z3k3@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        3 days ago

        This is always a concern however we were recently stung by the dicicert revocation thing. Spending a night changing thousands of certs was not fun

  • nazgul666@lemmy.world
    link
    fedilink
    arrow-up
    3
    ·
    edit-2
    5 days ago

    If I understand this correctly, it only affects certificates issued by public CAs (certificates for public websites, for example). So for certs issued by a company CA (e.g. for internal infrastructure), it should not apply. Can anyone confirm?

    • prime_number_314159@lemmy.world
      link
      fedilink
      arrow-up
      2
      ·
      3 days ago

      The browser warning appears even for a cert issued by a non public CA you have told your browser to trust, and most browsers already enforce a 398 day limit, so unless you have cooperative users, you’re already (effectively) capped at 1 year of validity.

      • lud@lemm.ee
        link
        fedilink
        arrow-up
        1
        ·
        3 days ago

        No, that’s fortunately not correct. TLS certificates issued by our CA are valid for 2 years and that works perfectly fine in all the browsers I have ever used.

  • SkaveRat@discuss.tchncs.de
    link
    fedilink
    arrow-up
    3
    arrow-down
    1
    ·
    4 days ago

    Doesn’t really affet me much, as my LE cronjob will update the cert either way. Doesn’t really matter if it’s 90 days or 47 (what a weird number of days)

    • ShortN0te@lemmy.ml
      link
      fedilink
      arrow-up
      2
      ·
      4 days ago

      I only can assume: 1.5 months rounded up, using 31 days a month 31+16=47

      So you get half a month to realize that your monthly automated renewal is broken?

  • reisub@discuss.tchncs.de
    link
    fedilink
    arrow-up
    4
    arrow-down
    3
    ·
    5 days ago

    I like it. This action is inevitable in my opinion, and there will always be legacy systems regardless of the timeline, better start sooner than later.