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.

  • tburkhol@slrpnk.net
    link
    fedilink
    English
    arrow-up
    47
    arrow-down
    1
    ·
    20 days ago

    I’m happy with 90 day certs for homelab stuff: I’m not worried about anyone MITMing my network. I figure the short lived certs are more important for people who provide services with a significant external user-base, or who process sensitive transactions.

    I have my certbot set to check every 12 hours and renew at 60 days. Renewing every 3 days would be 20x more load on Let’s Encrypt systems, and that feels like abuse of a free service for my use case.

  • sonstwas@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    15
    ·
    20 days ago

    Honest, non-techie question: How is it an advantage? Given modern crypto isnt it more likely that a mitm didn’t crack the crypto but instead got somehow else in the middle and just can “ignore” certs renewals?

    • BorgDrone@feddit.nl
      link
      fedilink
      English
      arrow-up
      25
      arrow-down
      1
      ·
      20 days ago

      Several reasons

      • If a private key leaks, a shorter certificate lifespan limits the fallout
      • Faster upgrades to new cryptographic standards. If some of the crypto methods used get broken, short lived certificates means they get replaced with newer methods faster
      • Short lived certificates force sysadmins to automate the renewal process. This prevents expired certificates due to forgetting the manual renewal.
      • Certificate lifetime and domain ownership mismatch. You could buy a 2 year certificate for somedomain.com and then sell the domain or just let it expire and have it picked up by someone else. You then have a valid certificate for a domain you no longer ow and you could MitM traffic for the new owner’s website.
      • ÚwÙ-Passwort@lemmy.world
        link
        fedilink
        English
        arrow-up
        9
        ·
        20 days ago

        My last job had an Onlineshop, 4years in a row the colleague dealing with ssl wad on vacation when the cert ran out.

        • chronicledmonocle@lemmy.world
          link
          fedilink
          English
          arrow-up
          6
          ·
          20 days ago

          Your colleague sucked at automation. Normally, I’d say no one should be bothered on vacation, but in this case you should have called him on his vacation, since he didn’t value anyone else’s time either.

          • roofuskit@lemmy.world
            link
            fedilink
            English
            arrow-up
            6
            ·
            20 days ago

            The manager sucked. There’s a lot of solutions to this issue but cross training and proper backup preparation are the most ideal ones.

        • Auli@lemmy.ca
          link
          fedilink
          English
          arrow-up
          2
          ·
          19 days ago

          ACME is automated. Since it is all automated they are shorting the life. If your not automated have fun or purchase a longer one.

      • undefinedTruth@lemmy.zip
        link
        fedilink
        English
        arrow-up
        6
        ·
        20 days ago

        Short lived certificates force sysadmins to automate the renewal process. This prevents expired certificates due to forgetting the manual renewal.

        That was already the case with the 90 day ones. No sane person is going to be manually renewing certificates every 3 months.

      • billwashere@lemmy.world
        link
        fedilink
        English
        arrow-up
        6
        ·
        19 days ago

        You make some good arguments so I’m not attacking you at all, just my thoughts on your points. These short renewal times are getting to the point of ridiculousness and creating another point of failure with little time to do anything about it. I find these super short certs less than useful, create many more possible problems, and not really necessary except for a small set of circumstances. And I have been in IT as a web dev/sys admin/systems architect for over 30 years now.

        • If a private key leaks you’ve likely done something wrong. Practice better key management and don’t be stupid
        • Updating certs to keep up with new crypto standards is useless. For one they don’t change that often and if there is a pressing reason you can’t update earlier.
        • Yes the processes have to be automated which is not a bad idea at all. But you are completely relying on the service to not be down and that something on your end hasn’t also broken. Anybody that hasn’t ever been a sys admin has had several automated process die for no apparent reason.
        • This could actually be an issue but totally out of your control. This is only relevant if you domain hop frequently and if your that worried about security, you aren’t doing that.
        • Auli@lemmy.ca
          link
          fedilink
          English
          arrow-up
          1
          ·
          19 days ago

          It is all automated so who cares. And if it is down for 3 days there is something wrong.

          • GameGod@lemmy.ca
            link
            fedilink
            English
            arrow-up
            4
            ·
            19 days ago

            If your automation breaks on day 1 of your vacation, you’re now forced to spend some of your vacation fixing it. Hope you were checking email.

    • corsicanguppy@lemmy.ca
      link
      fedilink
      English
      arrow-up
      4
      arrow-down
      1
      ·
      20 days ago

      You’re gonna get different viewpoints, ranging from “yeah, but it’s popular” to “shut up”.

    • Auli@lemmy.ca
      link
      fedilink
      English
      arrow-up
      1
      ·
      19 days ago

      Since the certificate revocation list doesn’t really work. They decided to shorten certificates lifespan. 90 days down to 45 and who knows what is next.

  • Auli@lemmy.ca
    link
    fedilink
    English
    arrow-up
    13
    ·
    19 days ago

    Yes, with Caddy and haven’t noticed a thing, and had no complaints. So it has been perfectly fine and it is all automated.

  • antsu@discuss.tchncs.de
    link
    fedilink
    English
    arrow-up
    12
    ·
    20 days ago

    I migrated from vanilla Nginx Proxy Manager to NPMplus (because of CrowdSec), and it defaults to short-lived certificates. Other than temporarily making my Uptime Kuma SSL monitors completely freak out because my certificates “were too close to expiration”, everything still works exactly the same.

    • eco_game@discuss.tchncs.de
      link
      fedilink
      English
      arrow-up
      3
      ·
      20 days ago

      Interesting, I didn’t know NPMplus was a thing. Looks like I’ve got some researching and possibly reconfiguring to do…

  • Harold@feddit.nl
    link
    fedilink
    English
    arrow-up
    10
    ·
    20 days ago

    Thank you for sharing. I had missed the announcement, so pleased to know the option is available.

    I have fully automated the creation and renewal of my certs and have just short of 50 certs that I manage in total. Every single one automated using NixOS / ACME / lego.

    Technically I could easily implement this, just have to switch my config.

    Honest question, are there any particular security benefits to this (especially for a home lab)?

    I can understand the short lived time span further reduces risk of compromise, yet the existing time span is already “much shorter than traditional certificates”. Does it have a substantial impact on our security posture?

    • plateee@piefed.social
      link
      fedilink
      English
      arrow-up
      3
      ·
      edit-2
      19 days ago

      At work, I used ssh-signed certificates for Linux server access - those certs are only valid for about 15 minutes.

      The whole idea of shorter lifetime certificates is to address if a certificate is compromised. (Especially for client certificates which, iirc, Let’s Encrypt no longer offers).

      For a home lab? With no externally accessible services? Short-lived certs aren’t really a big deal. Nobody is going to be hacking your homelab, stealing your private keys, poisoning your internal DNS, and pointing you to a different, malicious service.

      • tal@lemmy.today
        link
        fedilink
        English
        arrow-up
        2
        ·
        19 days ago

        If you’re a developer for an important open source project, they might.

        Attacking the xz project wasn’t done because the attacker cared about anything that the xz maintainer had. It was because he was trusted and the software he maintained had been given a fair bit of trust by certain maintainers and could be compromised and used as a vector into other systems that indirectly relied on that open-source project.

      • Harold@feddit.nl
        link
        fedilink
        English
        arrow-up
        2
        ·
        19 days ago

        I had no idea “single use certificates” were a thing. It makes sense, although from my personal perspective I have always worked with managed identities and privilege escalation.

        I have almost no internet facing services, although the two I have I might swap for the short lived variants. As you said, risk of misuse due to compromise goes down so that makes sense.

        For my other services, they are all running on HTTPS, but only available internally over LAN or VPN, all with isolated VLANs sort of like a Hub Spoke model. The two certs that are internet facing are basically for getting access to my VPN. Might swap the internal services to short lived anyway if the automation works well, as I said before, it’s fully automated anyway.

  • chunkystyles@sopuli.xyz
    link
    fedilink
    English
    arrow-up
    11
    arrow-down
    1
    ·
    19 days ago

    Everyone in here taking about an the automations they’ve done for certs and I just use Caddy. It handles all that for me.

    • lemmyvore@feddit.nl
      link
      fedilink
      English
      arrow-up
      2
      ·
      19 days ago

      Yeah but if you want to use something different, or may need to use different web servers or proxies from time to time, it’s better to have the cert renewal stuff separated.

      Also, for any provider that’s off the beaten path you have to build caddy yourself to include the right plugin and that’s just meh.

      Caddy’s fine if you only use one provider and only Caddy all the time but other than that no.

      • motruck@lemmy.zip
        link
        fedilink
        English
        arrow-up
        3
        ·
        18 days ago

        DNS for let’s encrypt via caddy integration and just have the same definition for all of your caddy servers and whatever you point your domains at will work as expected. Single config and redundancy with certs.

      • chunkystyles@sopuli.xyz
        link
        fedilink
        English
        arrow-up
        1
        ·
        18 days ago

        I’m already building a custom image of Caddy with plugins for Crowdsec integration. It’s not hard to do. But I have no reason to use anything other than the default Let’s Encrypt setup.

  • Ooops@feddit.org
    link
    fedilink
    English
    arrow-up
    5
    ·
    edit-2
    20 days ago

    Certbot came with a systemd timer running twice a day (0, 12 +12h random) that only renews –iirc– when the certificate has 30 days or less to live. Also I looked it up and my (version 6.7) Certbot neither mentions the option with the --help option, nor in the manual (where there is just one instance of “profiles exist, no other details given”).

    So they probably need another way than a random blog post when they want users to use (or even just know about) that option…

    It’s been pretty much a set-and-forget experience

    Yeah, that’s what it always has been. So no need to change anything unless they make it the new standard on their side with an update…

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

    I’m using Nginx Proxy Manager. Apparently my letsrenew certs are good for 2 yrs and I don’t see any way to configure that in the ui.

  • AnitaAmandaHuginskis@lemmy.world
    link
    fedilink
    English
    arrow-up
    4
    arrow-down
    1
    ·
    19 days ago

    I don’t know what the BFD is. Noone is supposed to handle certs manually anyway. OK, maybe companies that did not get the message but nowadays this is supposed to be automated and then it does not really matter whether the cert is valid for 90, 45, 30, or 6 days.

    For security, it does matter, shorter is better.

  • ipkpjersi@lemmy.ml
    link
    fedilink
    English
    arrow-up
    3
    arrow-down
    1
    ·
    19 days ago

    No, because I often use Cloudflare, and I end up getting emails when Cloudflare notices a new SSL cert, and I don’t want to get those emails every 6 days. I already get more than enough emails in general.