| ▲ | saagarjha 2 days ago |
| Seems not ideal for an entity who seems to be pushing for shorter expiration periods all the time |
|
| ▲ | Dylan16807 2 days ago | parent | next [-] |
| If it goes past 24 hours, that becomes a real worry. If anyone is renewing certificates with less than a day remaining, that's an issue on their end far more than anything else. |
|
| ▲ | xp84 2 days ago | parent | prev | next [-] |
| I think it’s mostly Apple and maybe Google who have the hard-ons for the shortest expiries possible. |
| |
| ▲ | fragmede 2 days ago | parent [-] | | To be fair, if someone managed to steal a set of keys to Gmail.com and icloud.com, I would want them to expire as short a time as possible too. | | |
| ▲ | spragl 2 days ago | parent | next [-] | | That is right, but one thing is not like the other. You have always been free to set expiry low on your own certificates, but that is not the same as enforcing it on everyones ceritificate. | |
| ▲ | notrealyme123 2 days ago | parent | prev [-] | | I think revoking them would be better in such a case. | | |
| ▲ | flakes 2 days ago | parent | next [-] | | One is not really better, you want both. Certificate revocation lists are loaded out of band and depending on the client can be poorly enforced. Questions come up: do you block a request if you fail to download the latest CRL? How often do you refresh it? When the cert expires, it can be removed from the CRL, so shorter lived certs will allow CRLs to be smaller and faster to transfer. | | |
| ▲ | naturalmovement 2 days ago | parent [-] | | > Questions come up: do you block a request if you fail to download the latest CRL? How often do you refresh it? In the before times we left settings like this up to competent system administrators to decide based on risk and not hardcoded by a handful of people at Google. | | |
| ▲ | dijit 2 days ago | parent [-] | | > competent system administrators Sorry, we don't hire those anymore. Best I can do is a YAML monkey who knows how to glue cloud services together.. | | |
| ▲ | icedchai 2 days ago | parent [-] | | So true. The last time I worked with a person with an actual "system administrator" title was 2009! |
|
|
| |
| ▲ | hdgvhicv 2 days ago | parent | prev [-] | | Revoking doesn’t really work. https://garantir.io/certificate-revocation-challenges-and-be... | | |
| ▲ | jzl 2 days ago | parent | next [-] | | Stale news. Mozilla introduced a new solution for certificate revocation that solves nearly all the problems with old methods. While it hasn't really taken off outside of Firefox, that's mostly because Google and Apple haven't embraced it because they are too busy trying to shorten certificate life unnecessarily. https://hacks.mozilla.org/2025/08/crlite-fast-private-and-co... | | |
| ▲ | hdgvhicv 2 days ago | parent | next [-] | | > While it hasn't really taken off outside of Firefox Thus doesn’t really work. Sadly. | |
| ▲ | zx8080 2 days ago | parent | prev [-] | | What is the reason that they are shortening it? |
| |
| ▲ | naturalmovement 2 days ago | parent | prev [-] | | Revocation doesn't work because a cabal of arrogant Googlenos and friends decided it's too hard to fix so we won't do it at all. The last browser where revocation worked properly is Internet Fucking Explorer. |
|
|
|
|
|
| ▲ | tonyhart7 2 days ago | parent | prev [-] |
| isn't this the other way around ??? because shorter expiration time resulting on more issuing cert and therefore make it more prone to downtime |
| |
