this post was submitted on 02 Dec 2025
469 points (99.2% liked)

Selfhosted

59897 readers
697 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam.

  3. Posts here are to be centered around self-hosting. Please ensure it is clear in your post how it relates to self-hosting.

  4. Don't duplicate the full text of your blog or git here. Just post the link for folks to click.

  5. Submission headline should match the article title.

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 3 years ago
MODERATORS
ruud@lemmy.world
Loki@lemmy.world
CannaVet@lemmy.world
devve@lemmy.world
ayyy@sh.itjust.works
curbstickle@anarchist.nexus
curbstickle_lw@lemmy.world
469
Decreasing Certificate Lifetimes to 45 Days (letsencrypt.org)
submitted 6 months ago by artiman@piefed.social 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
[–] Atemu@lemmy.ml 1 points 6 months ago (1 children)

Forgive my ignorance but why would that incur a downtime?

The only way I can think of for downtime to happen if you switched certs before the new one was signed (in which case ..don't) or am I missing something?

It also strikes me as weird that LE requires 80 but does allow insecure 443 after a redirect. Why not just do/allow insecure 443 in the first place?

[–] jj4211@lemmy.world 2 points 6 months ago (1 children)

the TLS-ALPN-01 challenge requires a https server that implements generating a self-signed certificate on demand in response to a specific request. So we have to shut down our usual traffic forwarder and let an ACME implementation control the port for a minute or so. It's not a long downtime, but irritatingly awkward to do and can disrupt some traffic on our site that has clients from every timezone so there's no universal '3 in the morning' time, and even then our service is used as part of other clients '3 in the morning' maintenance windows... Folks can generally take a blip in the provider but don't like that we generate a blip in those logs if they connect at just the wrong minute in a month...

As to why not support going straight to 443, don't know why not. I know they did TLS-ALPN-01 to keep it purely as TLS extensions to stay out of the URL space of services which had value to some that liked being able to fully handle it in TLS termination which frequently is nothing but a reverse proxy and so in principle has no business messing with payload like HTTP-01 requires. However for nginx at least this is awkward as nginx doesn't support it.

[–] Atemu@lemmy.ml 1 points 6 months ago

Thanks for the explanation!

Though it ought to be possible to only respond with the new self-signed cert when LE does the challenge and with the previous, properly signed cert otherwise.

I found https://codeberg.org/neilpang/acme.sh/wiki/TLS-ALPN-without-downtime which demonstrates one method to achieve that but I lack practical experience judge whether that's optimal.