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.

you are viewing a single comment's thread
view the rest of the comments
[–] 10 points 10 hours ago* (2 children)

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?

  • source
  • hideshow 2 child comments
  • [–] 2 points 4 hours ago* (last edited 4 hours ago) (1 child)

    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.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 3 hours 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.

  • source
  • parent