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

Selfhosted

53294 readers
1051 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
 

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.

(page 2) 50 comments
sorted by: hot top controversial new old
[–] Arghblarg@lemmy.ca 111 points 2 days ago (27 children)

So what's the floor here realistically, are they going to lower it to 30 days, then 14, then 2, then 1? Will we need to log in every morning and expect to refresh every damn site cert we connect to soon?

It is ignoring the elephant in the room -- the central root CA system. What if that is ever compromised?

Certificate pinning was a good idea IMO, giving end-users control over trust without these top-down mandated cert update schedules. Don't get me wrong, LetsEncrypt has done and is doing a great service within the current infrastructure we have, but ...

I kind of wish we could just partition the entire internet into the current "commercial public internet" and a new (old, redux) "hobbyist private internet" where we didn't have to assume every single god-damned connection was a hostile entity. I miss the comraderie, the shared vibe, the trust. Yeah I'm old.

[–] atzanteol@sh.itjust.works 97 points 2 days ago (9 children)

Will we need to log in every morning and expect to refresh every damn site cert we connect to soon?

Automate your certificate renewals. You should be automating updates for security anyway.

[–] dan@upvote.au 46 points 2 days ago* (last edited 2 days ago) (1 children)

This is one of the reasons they're reducing the validity - to try and convince people to automate the renewal process.

That and there's issues with the current revocation process (for incorrectly issued certificates, or certificates where the private key was leaked or stored insecurely), and the most effective way to reduce the risk is to reduce how long any one certificate can be valid for.

A leaked key is far less useful if it's only valid or 47 days from issuance, compared to three years. (note that the max duration was reduced from 3 years to 398 days earlier this year).

From https://www.digicert.com/blog/tls-certificate-lifetimes-will-officially-reduce-to-47-days:

In the ballot, Apple makes many arguments in favor of the moves, one of which is most worth calling out. They state that the CA/B Forum has been telling the world for years, by steadily shortening maximum lifetimes, that automation is essentially mandatory for effective certificate lifecycle management.

The ballot argues that shorter lifetimes are necessary for many reasons, the most prominent being this: The information in certificates is becoming steadily less trustworthy over time, a problem that can only be mitigated by frequently revalidating the information.

The ballot also argues that the revocation system using CRLs and OCSP is unreliable. Indeed, browsers often ignore these features. The ballot has a long section on the failings of the certificate revocation system. Shorter lifetimes mitigate the effects of using potentially revoked certificates. In 2023, CA/B Forum took this philosophy to another level by approving short-lived certificates, which expire within 7 days, and which do not require CRL or OCSP support.

[–] Passerby6497@lemmy.world 16 points 1 day ago (1 children)

note that the max duration was reduced from 3 years to 398 days earlier this year)

2020 really has been the longest year of my life

load more comments (1 replies)
[–] Goose@piefed.social 5 points 1 day ago* (last edited 1 day ago) (5 children)

That's a lot easier said that done for hobbyists that need a certificate for their home server. I will give you a real world example. I run Ubuntu Linux (but without snaps) on my main desktop machine, however like the person you replied to I am old and I don't have a good memory so when I do use Linux I try to take the easiest approach possible. But I also have a server running on a Raspberry Pi, and another family member (that has a Mac) that I exchange XMPP-based instant messages with. The server runs Prosody, and on my Ubuntu box I run Gajim (the one from the apt repository which is version 1.8.4, I have no idea why they won't put a newer version in the repo). The other family member uses some MacOS-based XMPP client. The problem is that if there is not a valid certificate on the server, Gajim refuses to send or receive anything other than plain-text messages. It won't sent or receive files or pictures, etc. unless the certificate is valid.

However the Raspberry Pi does other things as well (it would be silly to dedicate a Pi to just running Prosody) and one of those other things puts a pseudo-web server of sorts on port 80, which is only accessible from the local network. So I can't use Certbot because it insists on being able to connect to a web server. Even if I had a general web server on the Pi, which I don't have and don't want, it would be restricted for local access only. Also, I'm not paying for a DNS address for my own home server. What I found I could do is get a DuckDNS address (they are free) and use that to get a LE certificate. But the procedure is very manual and kind of convoluted, you have to ssh into the server using two separate sessions and enter some information in each one, because of the absolutely asinine way LE's renewal process works if you don't have a web server. I hate doing it every 90 days and if I have to do it every 45 days I'll probably just give up on sending and receiving files.

I should also mention that it took me hours to figure out the procedure i am using now, and it seems so stupid because I have that server locked down with two firewalls (one on the router and then iptables on the server) I don't even want a certificate but the designers of Gajim in their infinite wisdom(?) decided not to give users the option to in effect say "I trust this server, just ignore an expired or missing certificate." And the designers of LE never seemed to consider that some people might need a certificate that are not running a web server (and don't want to run one) and provide some automatic mechanism for renewing in that situation. And just because someone uses Linux does not mean we are all programmers or expert script writers. I can follow "cookbook" type instructions (that is the ONLY way I got Prosody set up) but I can't write a script or program to automate this process (again, I'm OLD).

I know somebody's going to be tempted to say I should use some other software (other that Prosody or Gajim). I tried other IM clients and Gajim is the only one that works the way I expect it to. As for Prosody, I have from time to time tried setting up other XMPP servers that people have suggested and could never get any of them to work. As I said, had I not found "cookbook" type instructions for setting up Prosody I would probably not be running that either, it was a PITA to get working but not that it IS working I don't want to go through that again. And Prosody isn't the problem, it works perfectly fine without a valid certificate, but pretty much every Linux IM client I have tried either loses functionality or won't work at all if the server doesn't have a valid certificate. And no I don't run or use Docker, nor do I have any desire to (especially on a Raspberry Pi).

EDIT: After giving this some thought I decided look further into this, and discovered that while Certbot can't handle this, it's possible that a script called acme.sh can. See https://github.com/acmesh-official/acme.sh?tab=readme-ov-file (also https://github.com/acmesh-official/acme.sh?tab=readme-ov-file#8-automatic-dns-api-integration - may need to scroll up just a bit, the pertinent item is "8. Automatic DNS API integration"). I haven't tried it yet (just manually renewed yesterday) but it looks promising if I can figure it out. Thought I'd post the links for anyone else that might be in the same situation.

load more comments (5 replies)
load more comments (7 replies)
[–] JASN_DE@feddit.org 32 points 2 days ago (1 children)

So what's the floor here realistically, are they going to lower it to 30 days, then 14, then 2, then 1?

LE is beta-testing a 7-day validity, IIRC.

Will we need to log in every morning and expect to refresh every damn site cert we connect to soon?

No, those are expected or even required to be automated.

[–] dan@upvote.au 24 points 2 days ago (1 children)

7-day validity is great because they're exempt from OCSP and CRL. Let's Encrypt is actually trying 6-day validity, not 7: https://letsencrypt.org/2025/01/16/6-day-and-ip-certs

Another feature Let's Encrypt is adding along with this is IP certificates, where you can add an IP address as an alternate name for a certificate.

load more comments (1 replies)
[–] yggstyle@lemmy.world 5 points 1 day ago (2 children)

Is this the same trust that would infect a box in under a minute if not behind a router?

The same trust of needing to scan anything you downloaded for script kiddie grade backdoors?

Zero click ActiveX / js exploits?

Man I'm probably the same age and those are some intense rose colored glasses 😅

load more comments (2 replies)
[–] ByteJunk@lemmy.world 11 points 1 day ago (2 children)

Partition the internet... Like during the Morris worm of '88, where they had to pull off regional networks to prevent the machines from being reinfected?

The good old days were, maybe, not that good. :)

[–] Arghblarg@lemmy.ca 4 points 1 day ago

Well that could be considered the point where we lost our innocence, yeah. :(

load more comments (1 replies)
load more comments (23 replies)
[–] Jozav@lemmy.world 41 points 1 day ago (3 children)

Reducing the validity timespan will not solve the problem, it only reduces the risk. And how big is that risk really? I'm an amateur and would love to see some real malicious case descriptions that would have been avoided had the certificate been revoked earlier...

Anybody have some pointers?

[–] groet@feddit.org 15 points 1 day ago

Terminology: revoked means the issuer of the certificate has decided that the certificate should not be trusted anymore even though it is still valid.

If a attacker gets access to a certificates key, they can impersonate the server until the validity period of the cert runs out or it is revoked by the CA. However ... revocation doesn't work. The revocation lists arent checked by most clients so a stolen cert will be accepted potentially for a very long time.

The second argument for shorter certs is adoption of new technology so certs with bad cryptographic algorithms are circled out quicker.

And third argument is: if the validity is so short you don't want to change the certs manually and automate the process, you can never forget and let your certs expire.

We will probably get to a point of single day certs or even one cert per connection eventually and every step will be saver than before (until we get to single use certs which will probably fuck over privacy)

No, but I have a link showing how ISPs and CAs colluded to do a MITM https://notes.valdikss.org.ru/jabber.ru-mitm/

Shorter cert lifespan would not prevent this.

load more comments (1 replies)
[–] Passerby6497@lemmy.world 32 points 2 days ago (2 children)

I've been dreading this switch for months (I still am, but I have been, too!) considering this year and next year will each double the amount of cert work my team has to do. But, I'm hopeful that the automation work I'm doing will pay off in the long run.

[–] non_burglar@lemmy.world 45 points 1 day ago (1 children)

Are you not using LE certbot to handle renewals? I can't even imagine doing this manually.

[–] Passerby6497@lemmy.world 32 points 1 day ago (2 children)

Personally, yes. Everything is behind NPM and SSL cert management is handled by certbot.

Professionally? LOL NO. Shit is manual and usually regulated to overnight staff. Been working on getting to the point it is automated though, but too many bespoke apps for anyone to have cared enough to automate the process before me.

[–] groet@feddit.org 6 points 1 day ago

One reason for the short certs is to push faster adoption of new technology. Yes that's about new cryptography in the certs but if you still change all your certs by hand maybe you need to be forced ...

[–] Zanathos@lemmy.world 3 points 1 day ago (1 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.

[–] LordKitsuna@lemmy.world 4 points 1 day ago (1 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

[–] Zanathos@lemmy.world 2 points 1 day ago (1 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.

[–] eclipse@lemmy.world 2 points 1 day 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?

[–] sparky@lemmy.federate.cc 2 points 1 day ago

That’s actually a really good idea. I’m not the person you replied to, but I’m taking notes.

load more comments (1 replies)
load more comments (1 replies)
[–] probable_possum@leminal.space 39 points 2 days ago* (last edited 2 days ago) (2 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 51 points 2 days ago (11 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 2 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.

load more comments (2 replies)
load more comments (10 replies)
[–] cron@feddit.org 30 points 2 days ago (5 children)

Short lifespans are also great when domains change their owner. With a 3 year lifespan, the old owner could possibly still read traffic for a few more years.

When the lifespan ist just 30-90 days, that risk is significatly reduced.

[–] probable_possum@leminal.space 1 points 23 hours ago* (last edited 23 hours ago) (1 children)

Moot point!

You could still get certificates for other people's domains from Honest Ahmed 's used cars and totally trustworthy CA or so. But that's another story. (there are A LOT of trusted CAs in everybody OS and browser. Do you know and trust them all?)

load more comments (1 replies)
load more comments (4 replies)
[–] CrabAndBroom@lemmy.ml 14 points 1 day ago (4 children)

I'm trying to think of the last time I heard news about something to do with the internet getting better instead of worse, and I'm genuinely coming up blank.

[–] eclipse@lemmy.world 6 points 1 day ago (1 children)

Automated certificates are relatively new and pretty neat. Killing off the certificate cartels is an added bonus.

load more comments (1 replies)
[–] nialv7@lemmy.world 10 points 1 day ago

Wait, how's this worse? This makes the Internet safer by reducing the window a leaked key can do harm.

load more comments (2 replies)
[–] imetators@lemmy.dbzer0.com 19 points 2 days ago (1 children)

As some selfhosting novice who uses NPM with auto renewal - I feel that I shouln't be ocncerned.

[–] mjr@infosec.pub 15 points 1 day ago

Check your autorenewal failure alerts go somewhere you'll react to.

load more comments
view more: ‹ prev next ›