4 ms·
I agree with you, but I suspect the intention is to prevent another type of timebomb. One where one day the system works and everything is considered secure, an
by jstanley 8y ago
I agree with you, but I suspect the intention is to prevent another type of timebomb. One where one day the system works and everything is considered secure, and then 25 years later nobody has given it a second thought.
- derefr 8y agoYes. Even then, a few years is too long, because you forget about the need for renewal. I would say that the "proper" use of certificate expiry is the way LetsEncrypt and other ACME providers do it: it's set so low that you need an automated renewal process in order to make the certificate at-all useful.
- jstanley 8y agoBut if it's automated, aren't we back to "forget about it for 25 years"?
- deleted 8y ago[deleted]
- zimbatm 8y agoBut then you need to make sure that the automated cert renewal system is still working...
- derefr 8y agoBut when automated cert-renewal breaks, it immediately breaks, and you start getting "cert renewal failed" messages in your email prompting you to action—but at that point, you still have time remaining to fix it before the cert expires, since ACME impls tend not to renew the cert exactly one second before it expires, but rather more like a day or two before it would expire. Unlike cert expiry, where the first you hear about it is when your production system stops working.
- wcoenen 8y agoBut of course, the failure emails will go to an email address that was deactivated a couple years ago because an employee left/everybody fired in reorg/unused address cleanup/domain migration/technical error/... Just this week I had someone complain to me that he was no longer getting build failure emails, and it turned out IT had disappeared our old <username>@<olddomain> addresses. That reminds me about an IT ticket I need to write.