11 ms·
Seriously? Any half decent administrator knows that for every SSL certificate you install, you set a date some time in the future where you need to change it ou
by modernpacifist 8y ago
Seriously? Any half decent administrator knows that for every SSL certificate you install, you set a date some time in the future where you need to change it out for a new one.
To your comment of "one day the system works normally and is deemed secure, and the next day it is so insecure and dangerous", this is working as intended. The certificate is to establish trust and identity along with encrypting the data in transit. The identity described by the certificate is only valid up until the expiry date after which it ceases to be valid for that purpose. You now have an encrypted connection to something that can't prove its identity, which is certainly a lower level of "secure" than what it was before the certificate expired.
Ignoring expiry dates would mean any keys that were compromised ever could be used for MITM attacks and no one would be the wiser.
- admax88q 8y agoExpiry dates are in years, if a key is compromised, then an adversary has _years_ to exploit a MITM. However we already mitigate this with revocation lists. But if we can revoke certificates why do we have expiration dates? Seems to me expiration dates are rent seeking behaviour by certificate vendors.
- jstanley 8y agoOne good reason is that if you buy a domain name that somebody else has used in the past, they don't have an infinite valid SSL certificate for your domain.
- AltF4me 8y agoWould it not be possible to expire the cert if the domain expires?
- toast0 8y agoNo. The certificate's expiration is fixed at time of issuance. You could set the expiration of the certificate to the expiration date of the domain, but the domain could be transferred, cancelled, or revoked before the expiration.
- wiml 8y agoNo, that would be "revocation". Expiration is relatively easy to implement because the expiration date is known in advance and so you can simply put the expiration date in the certificate when it is issued. Revocation is relatively difficult because you need to continually check some database for revocation information — that's where CRLs, OCSP, and the like come in. And there's a lot of complexity under that hood, which, once the dust settles, boils down to just issuing very-short-lived certificates under a different guise.
- nemothekid 8y agoThis is a reason to shorten expiration times, not remove them (which companies like LetsEncrypt are doing)
- admax88q 8y agoWhy. If revocation already works why bother with expiration?
- LinuxBender 8y agoJust a few years ago, almost nothing checked the revocation lists. I revoked certs for some popular domains and was concerned about ssl caches and proxies... turns out, an owl heard it. An odd dog barked. No impact. Not even from the folks that embedded our certs onto their servers for legacy code reasons. Perhaps this has changed over the last couple of years.
- admax88q 8y agoYep. But that's an implementation problem. Revocation is a critical security feature. Complaining that people didn't used to check it is like complaining that people didn't used to encrypt. You're not secure if you don't check revocation.
- LinuxBender 8y agoI agree with this. For the record, I am not complaining. :-) I just like to share my experiences of how things worked verses how they were intended to work.