this post was submitted on 02 Dec 2025
454 points (98.9% liked)

Selfhosted

53413 readers
402 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 posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

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

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

  7. No low-effort posts. This is subjective and will largely be determined by the community member reports.

Resources:

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

Questions? DM the mods!

founded 2 years ago
MODERATORS
ruud@lemmy.world
Loki@lemmy.world
CannaVet@lemmy.world
devve@lemmy.world
HybridSarcasm@lemmy.world
HybridSarcasm@lemmy.hybridsarcasm.xyz
454
Decreasing Certificate Lifetimes to 45 Days (letsencrypt.org)
submitted 5 days ago by artiman@piefed.social to c/selfhosted@lemmy.world
195 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
[–] probable_possum@leminal.space 38 points 5 days ago* (last edited 5 days ago) (21 children)

It's the "change your password often odyssey" 2.0. If it is safe, it is safe, it doesn't become unsafe after an arbitrary period of time (if the admin takes care and revokes compromised certs). If it is unsafe by design, the design flaw should be fixed, no?

Or am I missing the point?

[–] LastYearsIrritant@sopuli.xyz 52 points 5 days ago (13 children)

The point is, if the certificate gets stolen, there's no GOOD mechanism for marking it bad.

If your password gets stolen, only two entities need to be told it's invalid. You and the website the password is for.

If an SSL certificate is stolen, everyone who would potentially use the website need to know, and they need to know before they try to contact the website. SSL certificate revocation is a very difficult communication problem, and it's mostly ignored by browsers because of the major performance issues it brings having to double check SSL certs with a third party.

[–] mbirth@lemmy.ml 19 points 5 days ago (2 children)

The point is, if the certificate gets stolen, there's no GOOD mechanism for marking it bad.

That’s what OCSP is for. Only Google isn’t playing along as per that wiki entry.

[–] KairuByte@lemmy.dbzer0.com 2 points 4 days ago (1 children)

I mean, are you intending to retroactively add SSL to every tool implementing SSL in the past few decades?…

Browsers aren’t the only thing that ingress SSL.

[–] mbirth@lemmy.ml 1 points 4 days ago

Then there’s the older way of checking CRLs which any tool of the past few decades should support.

load more comments (10 replies)
load more comments (17 replies)