19 ms·

Let's Encrypt's old root certificate is expiring

195 points by zdw 5y ago

davidhyde 5y ago
I can see this being an issue for embedded systems that were set up before Let’s Encrypt added their new root authority. Some of these embedded systems won’t have an automatic way to update their trust anchors like browsers and operating systems typically do and so 30 September 2021 will be their Y2K date. RIP oh ye IOT toaster!
- CircleSpokes 5y ago
  Yeah such systems will be problematic. Those type of systems also have similar problems in cases where a certificate has been revoked. Thankfully that isn't a very big problem (at least at the moment).
- jeroenhd 5y ago
  If those devices require LE and still haven't received (automatic) updates already, I'd consider them IoT trash regardless. It's probably part of some IoT botnet already. Embedded devices that aren't updated regularly for long periods of time are the reason we can't have nice things on the internet.
  - DelightOne 5y ago
    I imagine Botnets may even have an interest in updating the devices themselves..
    - adrianN 5y ago
      The Invisible Hand keeping your IoT devices chugging along... interesting thought!
      - sysadmindotfail 5y ago
        It's not hard to imagine someone patching firmware out of sheer annoyance/efficiency. In fact, I bet someone can provide examples of product improvement along the journey of nefarious takeover.
    - jeroenhd 5y ago
      Botnets definitely tend to patch or secure devices they've taken over. Plenty of them kill the ssh or telnet daemon after getting access, and some even patch known vulnerabilities in the web interface. It's a weird battle for control over someone else's hardware.
  - nobody9999 5y ago
    >Embedded devices that aren't updated regularly for long periods of time are the reason we can't have nice things on the internet. No. Embedded devices should generally not be on the Internet at all. Rather, they should have local management/update points and zero access to the Internet. We still wouldn't be able to have nice things on the Internet, due to all the general purpose devices that have been compromised, but there's no reason a light bulb, a refrigerator, a TV or (especially) a camera or microphone should have any contact with the external world. But that breaks the "we're going to display ads on stuff you paid for, and if we spy on you, we can charge more for those ads" business model, and as such, I won't hold my breath and will continue to aggressively manage my DNS and network egress rules.
    - quaintdev 5y ago
      > No. Embedded devices should generally not be on the Internet at all. Rather, they should have local management/update points and zero access to the Internet. This! So much this. There should exist a gateway between these devices and Internet. IoT devices should not have to send data across the Interent in the first place unless user wants to access his home remotely.
  - White_Wolf 5y ago
    I would consider IOT trash any IOT device that demands/requires an internet connection to be functional. The same would apply to any smartphone that requires a sim on first start (or after factory reset). Embedded devices should not even be alowed online. Automatic updates I have mixed feelings about because they (sometimes) have a bad habit of breaking things and give me a ton of hassle.
    - xvector 5y ago
      Thread is the future of IoT. Finally a local mesh network that works.
      - Avamander 5y ago
        Not with that idiotic name. The authors deserve a strong paddling.
    - jeroenhd 5y ago
      Honestly, if the internet isn't required for the device to function, I think it shouldn't even be IoT in the first place. I think automatic updates should be part of the device's default lifecycle because nobody will download a ZIP and stick it onto a flash drive to update their fridge. If an automatic update bricks a device, it should be exchanged for free by either the point of sale or the manufacturer because it broke during normal operation. IoT vendors have been given far too much leeway and it's time they're held responsible for the crap they put on the internet.
      - White_Wolf 5y ago
        You can have IoT devices with LAN only. IoT doesn't mean that it needs to understand DNS and access WAN. For that you can have IoT gateways with proper security in place. The problem with "part of the device lifecycle" is planned obsolescence. I would be up for it though if manufacturers are forced to release the source code and all service information they have the same day they drop support/updates for a product. Edit: I don't think you realise how many applications of lot of "IoT" things have where they are only on a LAN with 0 internet access. Internet access should be optional, not mandatory.
- _jal 5y ago
  Let's hope for can't-connect-to-anything failure modes. The only thing worse than bricked electronic trash is functional, malicious electronic trash.
  - teddyh 5y ago
    This reminds me of how forests actually benefit from the occasional wildfire.
    - ehnto 5y ago
      It's integral to many ecosystems. I am also reminded of ChaosMonkey, the tool that would periodically take parts of your infrastructure down so you can make sure your failsafes actually work in the real world.
- SilverRed 5y ago
  >[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
- KronisLV 5y ago
  Why not just use self-signed certificates for those sorts of devices with a 50 year expiry or something like that? Surely setting up your CA or even embedding a single long term certificate (or chain) within your own device isn't too much a hassle, right? Realistically, your toaster, fridge or lightbulbs will only talk to a particular set of hosts within the vendor's walled garden, so there's no need to have a trust chain for the entirety of the Internet anyways. Provided that your IoT devices aren't doing anything shady otherwise. Assuming that you even need or want IoT devices.
  - lultimouomo 5y ago
    I am deploying a system where IoT devices first contact a bootstrap endpoint, authenticated by a private CA whose root cert is hardcoded in the device firmware. The bootstrap endpoint communicates the URL and CA root cert of the actual web services. This allows us to have the services themselves implemented as serverless functions using the cloud provider HTTPS/MQTT facilities. Does anyone see potential issues with that?
    - konschubert 5y ago
      The only issue is if the private key of your root Cert gets leaked. Then you won't have a way to issue a new one to your device.
    - teddyh 5y ago
      Even if the root cert is hardcoded, the root cert might still have an expiration date, and the firmware code might still check that.
      - lultimouomo 5y ago
        Good point. When this happens I'll be dead though, and so will be those devices. If we both turn out to be immortal I'll need to provide a firmware upgrade with a new CA root, possibly 10 years or so ahead of the expiration so every device has a chance to auto-upgrade.
tinus_hn 5y ago
So does this mean anything for clients worth supporting? I don’t care if some museum piece like an iPhone 4 no longer works.
- mixologic 5y ago
  I'm concerned that my smart tv might start to fail, or that older embedded devices that use http like my irrigation controller that gathers weather data from the internet might run into problems.
- tialaramex 5y ago
  If you care mostly about web browsers or equivalent technology, because you make an actual web site, for visiting with web browsers, probably no, everything is fine, anybody who would be broken by this is probably already annoyed for something else your modern site does. If your only TLS clients are under your control (e.g. you own an app, the app uses HTTPS or some other TLS protocol to talk to your servers) then you should be able to easily work out if there's any problem [edited to add: Hint, use a tool to wind their clock forward past the deadline by a day or so and see what happens] and decide whether and how to mitigate such problems. But, if you allow third parties (customers, suppliers, or worst of all, the General Public) to use some protocol (whether that's a RESTful HTTPS server or some custom text protocol from the 1980s) over TLS, you are potentially in for a lot of trouble when DST Root CA X3 expires and you should be on top of that by now. * If you need everybody and their dog to connect using rusty garbage from last century, too bad, figure out which certificates you need to pay $$$ for to make that happen and authorise the purchases today. In this case though I'm astonished Let's Encrypt has ever worked for you. DST Root X3 was widely accepted, but it was hardly the most popular. * If you can live with some clients dropping away e.g. because it's a free service anyway, or your SLA or other Ts&Cs say that you use Let's Encrypt and so it's actually in some sense "their problem" when this breaks, or you just hate money and love being sued, you can do nothing. * Otherwise you really need to figure out what fraction of your users will blow up. You should be capturing User Agent info (if HTTPS) and metrics on the types of cipher suite used and other fingerprints that can help you figure out what's connecting and thus what to expect. You need to be contacting "at risk" customers if possible to warn them what's about to happen and point them to resources for what they should do: 1. Software upgrades. Archaic OpenSSL is the biggest problem, if they can go to a much new OpenSSL it's much less likely they're suffering. 2. Trust store updates. By now, just telling them to rip out the (expiring) DST Root CA X3 cert if they have it might be easier than trying to figure out whether it's safe to leave it. But keep it or leave it, they need to make sure they trust ISRG Root X1.
atonse 5y ago
Does this even matter? If LE only issues 90 day certs there shouldn’t be any certs they’re signing with this CA Cert that are even valid now either way. If so then it’s yet another testament to their opinionated decision to only issue 90 day certs. (Which I strongly support)
- tialaramex 5y ago
  Nobody uses roots to sign End Entity certificates. That's been prohibited for years, and it was always a stupid practice even before it was specifically prohibited. But this is about root trust. Ultimately, why should your software trust this certificate, but not trust some random certificate I just made? If your system only trusts a Let's Encrypt certificate because of the DST Root CA X3 which is from like 2000, and then DST Root CA X3 expires, does your system no longer trust those certificates? If you make actual trust decisions, presumably you've made a few new ones since before the war in Afghanistan started and hopefully you trusted ISRG Root X1, from the organisation running Let's Encrypt. It's been around for a few years, you had time. More likely, you let your OS vendor make such decisions, don't worry all major OS vendors trusted ISRG Root X1 years ago. Apple, Microsoft, and (on behalf of the Free Unixes) Mozilla all OK'd this years and years back. But, if your software is a bit long in the tooth and was poorly made back then, that might not help. OpenSSL 1.0.0 was exciting when it happened, but that was a long time ago too and it didn't know how to handle this correctly. Old enough GnuTLS likewise.
  - atonse 5y ago
    Right but my point still stands. Even if you look at the trust chain: They would’ve signed intermediate certs along the way. The intermediate certs would’ve had Expirations before this month Certs signed with the intermediates would’ve expired sooner too. They would’ve stopped signing Intermediate certs for this a few years ago. So what’s the actual risk here? Are there certs out there that have this Cert as a root, with expirations past the lifetime of this root cert? How would that have even been allowed?
    - kxrm 5y ago
gorgoiler 5y ago
I tried my site from both Debian and iOS. (“openssl s_client” 1.1.1k and the HE.net app, respectively.) Debian shows a chain ending with the ISRG X1 cert that was signed by DST X3. iOS shows a chain ending with the self-signed ISRG X1. This happened even though Debian has the self-signed ISRT X1 installed as a root, and even if I delete the DST X3 from my list of roots. I don’t really understand how this can happen.
- spockz 5y ago
  I noticed that some clients/parsers, like OpenSSL are sensitive to the order of the certs in the chain (according to spec) whereas others try to “reconstruct” the tree visually.
cameronh90 5y ago
Is there any point in a root certificate that expires after 20 years? Any compromised root certificate will almost certainly be revoked before it naturally expires. Why not just make them root certificates indefinite and revoke them as part of the system trust anchor update process, at the same time as downloading new root certs? That way, you know that a revocation is only going to happen when it also pulls down replacement certificates.
- creatonez 5y ago
  > Any compromised root certificate will almost certainly be revoked before it naturally expires. How long will revocation lists have to be in the year 2100 if nothing expired?
  - cameronh90 5y ago
    I'm guessing root cert expiration data growth is much lower than storage density improvements. And of course you don't need to revoke a certificate that was never on the device in the first place.
cnst 5y ago
This is why noone should ever have adopted things like Let's Encrypt for their blogs and random portfolio websites in the first place. Especially not with disabling regular HTTP access. Will this be a wake-up call for everyone? Highly doubt it. The presumed "correct" solution is depreciation of all of those perfectly capable devices with gigabytes of memory and storage as outdated and broken, even though Google Search still works on all of them, as does any other website that's HTTPS-free, as would any other website that's using Let's Encrypt for no particularly good reason had they simply not adopted Let's Encrypt in the first place. HTTP still works and doesn't suffer from any of these compatibility problems. Anyone cares to calculate the environmental impact of this planned obsolescence action? The thing that's most annoying, however, is the loud insistence by a minority group that it's the devices that are at fault, not their insistence on using Let's Encrypt to secure things that are public information and aren't meant to be secured.

195 points by zdw 5y ago

I can see this being an issue for embedded systems that were set up before Let’s Encrypt added their new root authority. Some of these embedded systems won’t have an automatic way to update their trust anchors like browsers and operating systems typically do and so 30 September 2021 will be their Y2K date. RIP oh ye IOT toaster!

CircleSpokes 5y ago
Yeah such systems will be problematic. Those type of systems also have similar problems in cases where a certificate has been revoked. Thankfully that isn't a very big problem (at least at the moment).
jeroenhd 5y ago
If those devices require LE and still haven't received (automatic) updates already, I'd consider them IoT trash regardless. It's probably part of some IoT botnet already. Embedded devices that aren't updated regularly for long periods of time are the reason we can't have nice things on the internet.
- DelightOne 5y ago
  I imagine Botnets may even have an interest in updating the devices themselves..
  - adrianN 5y ago
    The Invisible Hand keeping your IoT devices chugging along... interesting thought!
    - sysadmindotfail 5y ago
      It's not hard to imagine someone patching firmware out of sheer annoyance/efficiency. In fact, I bet someone can provide examples of product improvement along the journey of nefarious takeover.
  - jeroenhd 5y ago
    Botnets definitely tend to patch or secure devices they've taken over. Plenty of them kill the ssh or telnet daemon after getting access, and some even patch known vulnerabilities in the web interface. It's a weird battle for control over someone else's hardware.
- nobody9999 5y ago
  >Embedded devices that aren't updated regularly for long periods of time are the reason we can't have nice things on the internet. No. Embedded devices should generally not be on the Internet at all. Rather, they should have local management/update points and zero access to the Internet. We still wouldn't be able to have nice things on the Internet, due to all the general purpose devices that have been compromised, but there's no reason a light bulb, a refrigerator, a TV or (especially) a camera or microphone should have any contact with the external world. But that breaks the "we're going to display ads on stuff you paid for, and if we spy on you, we can charge more for those ads" business model, and as such, I won't hold my breath and will continue to aggressively manage my DNS and network egress rules.
  - quaintdev 5y ago
    > No. Embedded devices should generally not be on the Internet at all. Rather, they should have local management/update points and zero access to the Internet. This! So much this. There should exist a gateway between these devices and Internet. IoT devices should not have to send data across the Interent in the first place unless user wants to access his home remotely.
- White_Wolf 5y ago
  I would consider IOT trash any IOT device that demands/requires an internet connection to be functional. The same would apply to any smartphone that requires a sim on first start (or after factory reset). Embedded devices should not even be alowed online. Automatic updates I have mixed feelings about because they (sometimes) have a bad habit of breaking things and give me a ton of hassle.
  - xvector 5y ago
    Thread is the future of IoT. Finally a local mesh network that works.
    - Avamander 5y ago
      Not with that idiotic name. The authors deserve a strong paddling.
  - jeroenhd 5y ago
    Honestly, if the internet isn't required for the device to function, I think it shouldn't even be IoT in the first place. I think automatic updates should be part of the device's default lifecycle because nobody will download a ZIP and stick it onto a flash drive to update their fridge. If an automatic update bricks a device, it should be exchanged for free by either the point of sale or the manufacturer because it broke during normal operation. IoT vendors have been given far too much leeway and it's time they're held responsible for the crap they put on the internet.
    - White_Wolf 5y ago
      You can have IoT devices with LAN only. IoT doesn't mean that it needs to understand DNS and access WAN. For that you can have IoT gateways with proper security in place. The problem with "part of the device lifecycle" is planned obsolescence. I would be up for it though if manufacturers are forced to release the source code and all service information they have the same day they drop support/updates for a product. Edit: I don't think you realise how many applications of lot of "IoT" things have where they are only on a LAN with 0 internet access. Internet access should be optional, not mandatory.
_jal 5y ago
Let's hope for can't-connect-to-anything failure modes. The only thing worse than bricked electronic trash is functional, malicious electronic trash.
- teddyh 5y ago
  This reminds me of how forests actually benefit from the occasional wildfire.
  - ehnto 5y ago
    It's integral to many ecosystems. I am also reminded of ChaosMonkey, the tool that would periodically take parts of your infrastructure down so you can make sure your failsafes actually work in the real world.
SilverRed 5y ago
>[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
KronisLV 5y ago
Why not just use self-signed certificates for those sorts of devices with a 50 year expiry or something like that? Surely setting up your CA or even embedding a single long term certificate (or chain) within your own device isn't too much a hassle, right? Realistically, your toaster, fridge or lightbulbs will only talk to a particular set of hosts within the vendor's walled garden, so there's no need to have a trust chain for the entirety of the Internet anyways. Provided that your IoT devices aren't doing anything shady otherwise. Assuming that you even need or want IoT devices.
- lultimouomo 5y ago
  I am deploying a system where IoT devices first contact a bootstrap endpoint, authenticated by a private CA whose root cert is hardcoded in the device firmware. The bootstrap endpoint communicates the URL and CA root cert of the actual web services. This allows us to have the services themselves implemented as serverless functions using the cloud provider HTTPS/MQTT facilities. Does anyone see potential issues with that?
  - konschubert 5y ago
    The only issue is if the private key of your root Cert gets leaked. Then you won't have a way to issue a new one to your device.
  - teddyh 5y ago
    Even if the root cert is hardcoded, the root cert might still have an expiration date, and the firmware code might still check that.
    - lultimouomo 5y ago
      Good point. When this happens I'll be dead though, and so will be those devices. If we both turn out to be immortal I'll need to provide a firmware upgrade with a new CA root, possibly 10 years or so ahead of the expiration so every device has a chance to auto-upgrade.

tinus_hn 5y ago

So does this mean anything for clients worth supporting? I don’t care if some museum piece like an iPhone 4 no longer works.

mixologic 5y ago
I'm concerned that my smart tv might start to fail, or that older embedded devices that use http like my irrigation controller that gathers weather data from the internet might run into problems.
tialaramex 5y ago
If you care mostly about web browsers or equivalent technology, because you make an actual web site, for visiting with web browsers, probably no, everything is fine, anybody who would be broken by this is probably already annoyed for something else your modern site does. If your only TLS clients are under your control (e.g. you own an app, the app uses HTTPS or some other TLS protocol to talk to your servers) then you should be able to easily work out if there's any problem [edited to add: Hint, use a tool to wind their clock forward past the deadline by a day or so and see what happens] and decide whether and how to mitigate such problems. But, if you allow third parties (customers, suppliers, or worst of all, the General Public) to use some protocol (whether that's a RESTful HTTPS server or some custom text protocol from the 1980s) over TLS, you are potentially in for a lot of trouble when DST Root CA X3 expires and you should be on top of that by now. * If you need everybody and their dog to connect using rusty garbage from last century, too bad, figure out which certificates you need to pay $$$ for to make that happen and authorise the purchases today. In this case though I'm astonished Let's Encrypt has ever worked for you. DST Root X3 was widely accepted, but it was hardly the most popular. * If you can live with some clients dropping away e.g. because it's a free service anyway, or your SLA or other Ts&Cs say that you use Let's Encrypt and so it's actually in some sense "their problem" when this breaks, or you just hate money and love being sued, you can do nothing. * Otherwise you really need to figure out what fraction of your users will blow up. You should be capturing User Agent info (if HTTPS) and metrics on the types of cipher suite used and other fingerprints that can help you figure out what's connecting and thus what to expect. You need to be contacting "at risk" customers if possible to warn them what's about to happen and point them to resources for what they should do: 1. Software upgrades. Archaic OpenSSL is the biggest problem, if they can go to a much new OpenSSL it's much less likely they're suffering. 2. Trust store updates. By now, just telling them to rip out the (expiring) DST Root CA X3 cert if they have it might be easier than trying to figure out whether it's safe to leave it. But keep it or leave it, they need to make sure they trust ISRG Root X1.

atonse 5y ago

Does this even matter? If LE only issues 90 day certs there shouldn’t be any certs they’re signing with this CA Cert that are even valid now either way. If so then it’s yet another testament to their opinionated decision to only issue 90 day certs. (Which I strongly support)

tialaramex 5y ago
Nobody uses roots to sign End Entity certificates. That's been prohibited for years, and it was always a stupid practice even before it was specifically prohibited. But this is about root trust. Ultimately, why should your software trust this certificate, but not trust some random certificate I just made? If your system only trusts a Let's Encrypt certificate because of the DST Root CA X3 which is from like 2000, and then DST Root CA X3 expires, does your system no longer trust those certificates? If you make actual trust decisions, presumably you've made a few new ones since before the war in Afghanistan started and hopefully you trusted ISRG Root X1, from the organisation running Let's Encrypt. It's been around for a few years, you had time. More likely, you let your OS vendor make such decisions, don't worry all major OS vendors trusted ISRG Root X1 years ago. Apple, Microsoft, and (on behalf of the Free Unixes) Mozilla all OK'd this years and years back. But, if your software is a bit long in the tooth and was poorly made back then, that might not help. OpenSSL 1.0.0 was exciting when it happened, but that was a long time ago too and it didn't know how to handle this correctly. Old enough GnuTLS likewise.
- atonse 5y ago
  Right but my point still stands. Even if you look at the trust chain: They would’ve signed intermediate certs along the way. The intermediate certs would’ve had Expirations before this month Certs signed with the intermediates would’ve expired sooner too. They would’ve stopped signing Intermediate certs for this a few years ago. So what’s the actual risk here? Are there certs out there that have this Cert as a root, with expirations past the lifetime of this root cert? How would that have even been allowed?
  - kxrm 5y ago

gorgoiler 5y ago

I tried my site from both Debian and iOS. (“openssl s_client” 1.1.1k and the HE.net app, respectively.) Debian shows a chain ending with the ISRG X1 cert that was signed by DST X3. iOS shows a chain ending with the self-signed ISRG X1. This happened even though Debian has the self-signed ISRT X1 installed as a root, and even if I delete the DST X3 from my list of roots. I don’t really understand how this can happen.

spockz 5y ago
I noticed that some clients/parsers, like OpenSSL are sensitive to the order of the certs in the chain (according to spec) whereas others try to “reconstruct” the tree visually.

cameronh90 5y ago

Is there any point in a root certificate that expires after 20 years? Any compromised root certificate will almost certainly be revoked before it naturally expires. Why not just make them root certificates indefinite and revoke them as part of the system trust anchor update process, at the same time as downloading new root certs? That way, you know that a revocation is only going to happen when it also pulls down replacement certificates.

creatonez 5y ago
> Any compromised root certificate will almost certainly be revoked before it naturally expires. How long will revocation lists have to be in the year 2100 if nothing expired?
- cameronh90 5y ago
  I'm guessing root cert expiration data growth is much lower than storage density improvements. And of course you don't need to revoke a certificate that was never on the device in the first place.

cnst 5y ago

This is why noone should ever have adopted things like Let's Encrypt for their blogs and random portfolio websites in the first place. Especially not with disabling regular HTTP access. Will this be a wake-up call for everyone? Highly doubt it. The presumed "correct" solution is depreciation of all of those perfectly capable devices with gigabytes of memory and storage as outdated and broken, even though Google Search still works on all of them, as does any other website that's HTTPS-free, as would any other website that's using Let's Encrypt for no particularly good reason had they simply not adopted Let's Encrypt in the first place. HTTP still works and doesn't suffer from any of these compatibility problems. Anyone cares to calculate the environmental impact of this planned obsolescence action? The thing that's most annoying, however, is the loud insistence by a minority group that it's the devices that are at fault, not their insistence on using Let's Encrypt to secure things that are public information and aren't meant to be secured.