6 ms·

>[moved] to their own root, ISRG Root X1, that expires on 4th June 2035, giving us quite a number of years. This seems like it makes the problem even worse. If

>[moved] to their own root, ISRG Root X1, that expires on 4th June 2035, giving us quite a number of years. This seems like it makes the problem even worse. If these certs expired every year or so, embedded/IoT vendors would not get away with fixing something that eventually expires since it would expire too quickly.

michaelt 5y ago
Do you have a solution for these certificates expiring which: (a) Doesn't involve creating a different certificate which never expires, and (b) Still works if a user leaves a device powered off in storage for a few years If so I'd love to hear it!
- xxpor 5y ago
  We should move to never expires. What good does a cert that expires in 15 years do other than setup a ticking time bomb. On the other hand, leaf certs should expire every day. Or at most a week. Move to new root certs when the tech calls for it (like SHA1->SHA256)
  - devrand 5y ago
    The only practical benefit I can imagine is that it puts a deadline on the damage from a root compromise. Not sure how much that's actually worth though. If you're designing a device that cannot be updated (or won't be), you probably shouldn't use Web PKI. Even if the roots didn't expire, I'm sure the BRs would eventually evolve to preclude issuing leaf certs compatible with the devices.
    - deleted 5y ago
      [deleted]
  - notriddle 5y ago
    The old Let's encrypt root certificate (DST Root CA X3 [1]) was from 2001, was signed with sha1, and is 2048 bit RSA. What criteria would you use to decide expiration dates for 20 years in the future? [1]: https://crt.sh/?id=8395 https://crt.sh/?id=8395
    - anderskaseorg 5y ago
      To be clear, the self-signature on a root certificate is meaningless (it only exists so that root certificates can be parsed with the same code as intermediate and leaf certificates); using SHA-1 there is not a risk. https://www.entrust.com/blog/2014/04/need-sha-2-signed-root-certificates/ https://www.entrust.com/blog/2014/04/need-sha-2-signed-root-...
    - robertlagrant 5y ago
      Let's Encrypt was only founded in 2014, and left beta in April 2016; they just used that cert to start with IIRC. So it's been about 5 years for LE users, not 20.
- SilverRed 5y ago
  Have a certificate updater system which will respect an expired certificate for the sole purpose of fetching the latest certificates. What difference is there between having a cert that lasts 15 years or one that lasts a single year but can fetch a new list even if expired. Everything else can still be confined to the regular expiry rules, just the certificate renewal job is exempt.
  - dsr_ 5y ago
    Good idea, let's change that slightly. Require a new cert to be available at a standard path, not less than 10 days before the previous expiration date for ordinary websites, and not less than 1 year before the previous expiration date for long-lived certs. Then part of the standard utilities in any SSL library should be the autoupdater, which recognizes that a cert should have an update available and takes care of that, emitting loud warnings if the replacement is not available in the appropriate window.

michaelt 5y ago

Do you have a solution for these certificates expiring which: (a) Doesn't involve creating a different certificate which never expires, and (b) Still works if a user leaves a device powered off in storage for a few years If so I'd love to hear it!

xxpor 5y ago
We should move to never expires. What good does a cert that expires in 15 years do other than setup a ticking time bomb. On the other hand, leaf certs should expire every day. Or at most a week. Move to new root certs when the tech calls for it (like SHA1->SHA256)
- devrand 5y ago
  The only practical benefit I can imagine is that it puts a deadline on the damage from a root compromise. Not sure how much that's actually worth though. If you're designing a device that cannot be updated (or won't be), you probably shouldn't use Web PKI. Even if the roots didn't expire, I'm sure the BRs would eventually evolve to preclude issuing leaf certs compatible with the devices.
  - deleted 5y ago
    [deleted]
- notriddle 5y ago
  The old Let's encrypt root certificate (DST Root CA X3 [1]) was from 2001, was signed with sha1, and is 2048 bit RSA. What criteria would you use to decide expiration dates for 20 years in the future? [1]: https://crt.sh/?id=8395 https://crt.sh/?id=8395
  - anderskaseorg 5y ago
    To be clear, the self-signature on a root certificate is meaningless (it only exists so that root certificates can be parsed with the same code as intermediate and leaf certificates); using SHA-1 there is not a risk. https://www.entrust.com/blog/2014/04/need-sha-2-signed-root-certificates/ https://www.entrust.com/blog/2014/04/need-sha-2-signed-root-...
  - robertlagrant 5y ago
    Let's Encrypt was only founded in 2014, and left beta in April 2016; they just used that cert to start with IIRC. So it's been about 5 years for LE users, not 20.
SilverRed 5y ago
Have a certificate updater system which will respect an expired certificate for the sole purpose of fetching the latest certificates. What difference is there between having a cert that lasts 15 years or one that lasts a single year but can fetch a new list even if expired. Everything else can still be confined to the regular expiry rules, just the certificate renewal job is exempt.
- dsr_ 5y ago
  Good idea, let's change that slightly. Require a new cert to be available at a standard path, not less than 10 days before the previous expiration date for ordinary websites, and not less than 1 year before the previous expiration date for long-lived certs. Then part of the standard utilities in any SSL library should be the autoupdater, which recognizes that a cert should have an update available and takes care of that, emitting loud warnings if the replacement is not available in the appropriate window.