5 ms·

Why do certificates expire? How is it acceptable to have a piece of data somewhere that contains a timebomb that must be periodically defused? I do not see ho

Why do certificates expire? How is it acceptable to have a piece of data somewhere that contains a timebomb that must be periodically defused? I do not see how this helps security, and it is particularly ridiculous that normal behavior is that one day the system works normally and is deemed secure, and the next day it is so insecure and dangerous that communication simply fails.

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 ago
  Yes. 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 ago
    But if it's automated, aren't we back to "forget about it for 25 years"?
    - deleted 8y ago
      [deleted]
  - zimbatm 8y ago
    But then you need to make sure that the automated cert renewal system is still working...
    - derefr 8y ago
      But 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 ago
        But 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.
kodablah 8y ago
> Why do certificates expire? I always assumed one reason is so revocation lists don't become huge. Also, digital properties such as domains change hands.
bluGill 8y ago
The problem is what is someone screws up and compromises the key? By having an expiration we ensure that in the worst case they get just a few years to do damage.
- noobermin 8y ago
  >just a few years of damage. Something in there is telling you that you're doing the worst of both worlds, by allowing such a huge gap between renewals that people merely forget leading to outages, and such a huge gap that if a key is to expire, someone else could use it for years before someone notice and actually revoke the old key. derefr above has the correct response.
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 ago
  Expiry 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 ago
    One 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 ago
      Would it not be possible to expire the cert if the domain expires?
      - toast0 8y ago
        No. 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.
jcranmer 8y ago
Cryptography is basically a computational treadmill: you want to make it cheap enough that it's not burdensome for the actual users, but that reversing the information without the key is computationally expensive. Processing power, especially for the highly parallelizable task of grinding through potential keys, follows an exponential curve; ergo, even the present exponential gap is not a long-term protection mechanism. The expiry date of a certificate was present in the original implementation of X.509 certificates; the infrastructure for certificate revocation lists was added later. Furthermore, a certificate revocation list includes every certificate ever revoked that has yet to expire. If you relied on certifcate revocation for expiring old certificates as well, that would be a nasty long file you'd have to download before you can start connecting to any website.
- hamandcheese 8y ago
  I think the much more important reason for expiring certificates is to minimize the damage in the case that your private keys are stolen, which is far more likely than them being brute forced.
geofft 8y ago
Attestation of identity should be seen as a service, not a product. Revocation exists. The fact that certificates are pieces of data is a compromise, not an ideal design. Most CAs already support OCSP, which is effectively one-day-long certificates: the client can contact the OCSP server for a signed response saying "yes, it's still unrevoked", or the server can include ("staple") such a response along with its certs. Some certs have the MustStaple extension, indicating that they should not be treated as valid unless a recent OCSP response is stapled to it. If we had the computational resources to just not have certificates at all and have every client check the CA's current belief that a public key belongs to a name at each use (and magically avoid the associated privacy problems), that would be ideal. Certificates are an approximation. One neat thing about 3-month certificates is that it's a meaningfully different human lifescale from a year (or multiple years): operators may not still be around in a year but will certainly be around in 3 months. Operators may just plan to manually renew in a few years, but generally decide they need to automate the process if it's every 3 months. (For extremely boring reasons, I manually update the certificate on my personal website every 3 months and it's a pain, and I think I am one of very few people who do manual updates to their Let's Encrypt certs.) So it forces people to think of certificates as running their end of a service with ongoing operational work, not a one-time transfer of data.

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 ago
Yes. 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 ago
  But if it's automated, aren't we back to "forget about it for 25 years"?
  - deleted 8y ago
    [deleted]
- zimbatm 8y ago
  But then you need to make sure that the automated cert renewal system is still working...
  - derefr 8y ago
    But 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 ago
      But 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.

kodablah 8y ago

> Why do certificates expire? I always assumed one reason is so revocation lists don't become huge. Also, digital properties such as domains change hands.

bluGill 8y ago

The problem is what is someone screws up and compromises the key? By having an expiration we ensure that in the worst case they get just a few years to do damage.

noobermin 8y ago
>just a few years of damage. Something in there is telling you that you're doing the worst of both worlds, by allowing such a huge gap between renewals that people merely forget leading to outages, and such a huge gap that if a key is to expire, someone else could use it for years before someone notice and actually revoke the old key. derefr above has the correct response.

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 ago
Expiry 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 ago
  One 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 ago
    Would it not be possible to expire the cert if the domain expires?
    - toast0 8y ago
      No. 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.

jcranmer 8y ago

Cryptography is basically a computational treadmill: you want to make it cheap enough that it's not burdensome for the actual users, but that reversing the information without the key is computationally expensive. Processing power, especially for the highly parallelizable task of grinding through potential keys, follows an exponential curve; ergo, even the present exponential gap is not a long-term protection mechanism. The expiry date of a certificate was present in the original implementation of X.509 certificates; the infrastructure for certificate revocation lists was added later. Furthermore, a certificate revocation list includes every certificate ever revoked that has yet to expire. If you relied on certifcate revocation for expiring old certificates as well, that would be a nasty long file you'd have to download before you can start connecting to any website.

hamandcheese 8y ago
I think the much more important reason for expiring certificates is to minimize the damage in the case that your private keys are stolen, which is far more likely than them being brute forced.

geofft 8y ago

Attestation of identity should be seen as a service, not a product. Revocation exists. The fact that certificates are pieces of data is a compromise, not an ideal design. Most CAs already support OCSP, which is effectively one-day-long certificates: the client can contact the OCSP server for a signed response saying "yes, it's still unrevoked", or the server can include ("staple") such a response along with its certs. Some certs have the MustStaple extension, indicating that they should not be treated as valid unless a recent OCSP response is stapled to it. If we had the computational resources to just not have certificates at all and have every client check the CA's current belief that a public key belongs to a name at each use (and magically avoid the associated privacy problems), that would be ideal. Certificates are an approximation. One neat thing about 3-month certificates is that it's a meaningfully different human lifescale from a year (or multiple years): operators may not still be around in a year but will certainly be around in 3 months. Operators may just plan to manually renew in a few years, but generally decide they need to automate the process if it's every 3 months. (For extremely boring reasons, I manually update the certificate on my personal website every 3 months and it's a pain, and I think I am one of very few people who do manual updates to their Let's Encrypt certs.) So it forces people to think of certificates as running their end of a service with ongoing operational work, not a one-time transfer of data.