Since the beginning of this year, Let’s Encrypt rolled out a new shortlived profile for certificates that make them valid for only 160 hours. The intention, as they say, is to encourage automation and reduce the window of certificate compromise (because revocation is somewhat a flakey thing).

Yet, I haven’t seen a lot of news about it since then. Hence the question: is this shorter cert thingy something you considered and deployed for your homelab?

As for me I’ve set up lego-acme with profile: "shortlived" on my rig. Lego runs on a bihourly cronjob, but only renews when a cert has >=3 days to expiry. It’s been pretty much a set-and-forget experience, although some more monitoring would be nice.

  • dan@upvote.au
    link
    fedilink
    English
    arrow-up
    7
    arrow-down
    1
    ·
    edit-2
    22 hours ago

    A private key leaking is bad, since anyone with the private key can decrypt data that was encrypted with it.

    Traditionally, the way that leaked certs were handled was via Certificate Revocation Lists (CRL). CRLs contain lists of revoked certificates - their serial number, revocation date, and the reason why they were revoked.

    However, CRLs are imperfect. Checking for revoked certificates every time you go to a site would slow things down a lot, as the lists are now too large to check and download real-time. Modern browsers and other TLS clients periodically download the lists in the background. Also, it might take a while between when the certificate is compromised and when the company notices the compromise.

    Because of this, the CA/Browser forum (a group with all the major browser and TLS certificate vendors) have started dropping the max lifetime of certificates. The idea is that even if a private key does leak, the time frame that it’s usable for will be significantly shorter and any leaks should (in theory) cause less damage.

    • The original maximum duration was 39 months: Three years plus an extra three months leeway for obtaining and deploying new certificates.
    • March 2018: Reduced to 825 days
    • September 2020: Reduced to 398 days
    • March 2026: Reduced to 200 days
    • March 2027: Planned to reduce to 100 days
    • March 2028: Planned to reduce to 47 days

    All modern deployments, regardless of if they’re using free or paid certs, should have their renewals fully-automated, so in theory the validity period shouldn’t matter as much as it did in the past. All major vendors (Let’s Encrypt, DigiCert, Sectigo, GlobalSign, AWS, SSL .com, etc) support ACME now. Reducing the validity is also a forcing function t o ensure automation is actually implemented.

    somehow else in the middle and just can “ignore” certs renewals?

    I’m not sure that’s possible, since an attacker in the middle shouldn’t be able to obtain a valid certificate for the domain. Certificates have a “not valid after” date encoded into them, after which the certificate is considered invalid and you get an error.