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.

  • bamboo@lemmy.blahaj.zone
    link
    fedilink
    English
    arrow-up
    0
    ·
    7 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.