Comment on Decreasing Certificate Lifetimes to 45 Days
Arghblarg@lemmy.ca 8 hours ago
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.
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.
7-day validity is great because they’re exempt from OCSP and CRL. Let’s Encrypt is actually trying 6-day validity, not 7: 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.
Ah, well. I only remembered something about a week.
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. :)
Will we need to log in every morning and expect to refresh every damn site cert we connect to soon?
Certbots by default checks twice a day if it’s old enough to be be due for a renewal… So a change from 90 to 1 day will in practice make no difference already…
The current plan is for the floor to be 47 days. digicert.com/…/tls-certificate-lifetimes-will-off…
The best approach for securing our CA system is the “certificate transparency log”. All issued certificates must be stored in separate, public location. Browsers do not accept certificates that are not there.
This makes it impossible for malicious actors to silently create certificates. They would leave traces.
Isn’t this just CRL in reverse? Part of the point of cryptographically signing a cert is so you don’t have to do this if you trust the issuer.
No, these are completely separate issues.
This is just one example why we have certificate transparency. Revocation wouldn’t be useful if it isn’t even known which certificates need revocation.
The National Informatics Centre (NIC) of India, a subordinate CA of the Indian Controller of Certifying Authorities (India CCA), issues rogue certificates for Google and Yahoo domains. NIC claims that their issuance process was compromised and that only four certificates were misissued. However, Google is aware of misissued certificates not reported by NIC, so it can only be assumed that the scope of the breach is unknown.
Or the more likely a rouge certificate authority giving out certs it shouldn’t.
This seems like a good idea.
The only disadvantage I see is that all my personal subdomains (e.g. immich.name.com and jellyfin) are forever stored in a public location. I wouldn’t call it a privacy nightmare, yet it isn’t optimal.
There are two workarounds:
But how to automate wildcard certificate generation? That requires a change of the txt record and namecheap for instance got no mechanism for that to automatically happen on cert bot action
Not exactly what you mean because there are also bad actors but take a look at i2p, in some ways it feels like an retro internet.
Seeing as most root CA are stored offline compromising a server turned off is not really possible.
Signing (intermediate) certs have been compromised before. That means a bad actor can issue fake certs that are validated up to your root ca certs
While you can invalidate that signing cert, without useful and ubiquitous revocation lists, there’s nothing you can do to propagate that.
A compromised signing certs, effectively means invalidating the ca cert, to limit the damage
Oh, I’m really just pining for the days before the ‘Eternal September’, I suppose. We can’t go back, I know. :/
atzanteol@sh.itjust.works 7 hours ago
Automate your certificate renewals. You should be automating updates for security anyway.
billwashere@lemmy.world 2 hours ago
But can you imagine the load on their servers should it come to this? And god forbid it goes down for a few hours and every person in the world is facing SSL errors because Let’s Encrypt can’t create new ones.
This continued shortening of lifespans on these certs is untenable at best. Personally I have never run into a situation where a cert was stolen or compromised but obviously that doesn’t mean it doesn’t happen. I also feel like this is meant to automate all cert production which is nice if you can. Right now, at my job, all cert creation requires manually generating a CSR, submit it to a website, wait for manager approval, and then wait for creation. Then go download the cert and install it manually.
If I have to do this everyday for all my certs I’m not going to be happy. Yes this should be automated and central IT is supposed to be working on it but I’m not holding my breath.
dan@upvote.au 7 hours ago
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.
From digicert.com/…/tls-certificate-lifetimes-will-off…:
Passerby6497@lemmy.world 2 hours ago
2020 really has been the longest year of my life
dan@upvote.au 44 minutes ago
Oh… Oops. Hahaha