←back to thread

F-Droid site certificate expired

(gitlab.com)
155 points kxxt | 8 comments | 31 Aug 25 12:16 UTC | HN request time: 0s | source | bottom
Show context
gethly ◴[31 Aug 25 14:32 UTC] No.45083427[source]▶
Because those ephemeral LE certificates are such a great idea...
replies(6): >>45083455 #>>45083516 #>>45083798 #>>45083991 #>>45084464 #>>45088393 #
shaky-carrousel ◴[31 Aug 25 14:43 UTC] No.45083516[source]▶
It is, if your objective is to closely centralize the web. If you make https mandatory, via scare tactics, only people with certificates will have websites. If you make ephemeral certificates mandatory by taking advantage of a monopoly, then only big SSL providers who can afford it will survive.

Then, when you have only two or three big SSL providers, it's way easier to shut someone off by denying them a certificate, and see their site vanish in mere weeks.

replies(6): >>45083645 #>>45083750 #>>45083879 #>>45084701 #>>45086962 #>>45090198 #
crazygringo ◴[31 Aug 25 15:08 UTC] No.45083750[source]▶
You don't need short expirations for that. CRLs/OCSP already provided a mechanism for certificates to be revoked before they expire.

However, short expirations severely limit the damage an attacker can do if they steal your private key.

And they avoid the situations where an organization simply forgets to renew a cert, because automating something so infrequent is genuinely difficult from an organizational standpoint. Employees leave, calendar reminders go missing, and yeah.

replies(4): >>45083802 #>>45084081 #>>45084499 #>>45085656 #
1. m-p-3 ◴[31 Aug 25 15:45 UTC] No.45084081[source]▶
CRLs are becoming bulky, and OCSP have some privacy implications (telling the CA which websites you visit), plus most browsers are set to soft fail if there's an outage and the request can't be made instead of a hard fail and making the website inaccessible, reducing the security and usefulness of OCSP.

Short-lived certificates fixes these issues from an end-user standpoint.

replies(2): >>45084174 #>>45086313 #
2. ozim ◴[31 Aug 25 15:59 UTC] No.45084174[source]▶
There are new solutions for CRL just last month:

https://hacks.mozilla.org/2025/08/crlite-fast-private-and-co...

replies(2): >>45084438 #>>45084449 #
3. aaomidi ◴[31 Aug 25 16:29 UTC] No.45084438[source]▶
This has existed for a while. It doesn’t address another major issue with revocation: user agents that aren’t browsers don’t implement it.
4. crazygringo ◴[31 Aug 25 16:30 UTC] No.45084449[source]▶
Yup. If your primary goal was fast, efficient certificate revocation, then having certs that still take 90 days to expire rather than 2 years is not the solution you'd come up with.

CRLite updates every 12 hours.

replies(1): >>45086154 #
5. ozim ◴[31 Aug 25 19:17 UTC] No.45086154{3}[source]▶
If you have short validity times for certificates it also means you have shorter CRL.
replies(1): >>45090587 #
6. TedDoesntTalk ◴[31 Aug 25 19:33 UTC] No.45086313[source]▶
Is it possible that one day certificate expiration will be a thing of the past?
replies(1): >>45087397 #
7. LtWorf ◴[31 Aug 25 21:46 UTC] No.45087397[source]▶
How would they get recurring revenue/donations then?
8. crote ◴[01 Sep 25 08:01 UTC] No.45090587{4}[source]▶
Not by definition. The main issue is mass revocation events: the CRL is still going to initially contain up to 100% of certs currently active, and the number of active certs won't meaningfully change.

It'll rapidly shrink over time as certs expire, but you still have to deal with that initial massive set.