468
Decreasing Certificate Lifetimes to 45 Days (letsencrypt.org)
submitted 9 months ago by to c/selfhosted@lemmy.world
196 comments fedilink hide all child comments
 

Let’s Encrypt will be reducing the validity period of the certificates we issue. We currently issue certificates valid for 90 days, which will be cut in half to 45 days by 2028.
This change is being made along with the rest of the industry, as required by the CA/Browser Forum Baseline Requirements, which set the technical requirements that we must follow. All publicly-trusted Certificate Authorities like Let’s Encrypt will be making similar changes. Reducing how long certificates are valid for helps improve the security of the internet, by limiting the scope of compromise, and making certificate revocation technologies more efficient.

you are viewing a single comment's thread
view the rest of the comments
[–] 2 points 9 months ago (5 children)

I'm in the same boat here. I keep sounding the alarm and am making moves so that MY systems won't be impacted, but it's not holding water with the other people I work with and the systems they manage. I'm torn between manual intervention to get it started or just letting them deal with it themselves once we hit 45 day renewal periods.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 4 points 9 months ago (4 children)

    Can you not just setup an nginx reverse proxy at the network edge to handle the ssl for the domain(s) and not have to worry about the app itself being setup for it? That's how I've always managed all software personal or professional

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 2 points 9 months ago (3 children)

    Unfortunately some apps require the certificate be bound to the internal application, and need to be done so through cli or other methods not easily automated. We could front load over reverse proxy but we would still need to take the proxy cert and bind to the internal service for communication to work properly. Thankfully that's for my other team to figure out as I already have a migration plan for systems I manage.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 3 points 9 months ago (2 children)

    Why can't you just have a long lived internally signed cert on your archaic apps and LE at the edge on a modern proxy? It's easy enough to have the proxy trust the internal cert and connect to your backend service that shouldn't know the difference if there's a proxy or not.

    Or is your problem client side?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 9 months ago

    One such app I can think of would be a client side issue. If the public cert doesnt match the back end private cert it will sever the connection and mark it as insecure. Hopefully I won't need to deal with it much longer though.

    I just heard back from my other team that "this project sounds great for your team" even though they manage many of their own apps and certificates. Perhaps I should just let them burn then!

  • permalink
  • fedilink
  • source
  • parent