Why? Shorter expiry times don’t require any new browser support, 90 days certificates will continue to be available, shorter certs are opt-in, and other TLS certificate providers are available (even if your parameters are “free” and “supports ACME”).
It puts a lot more centralized dependency on LetsEncrypt. If your site has to get a new cert every 6 days and something happens to LE, your site is now unusable without intervention.
It’s not out of the realm of possibility that an attacker could force LE’s issuing/validating servers offline for 6 days (which is also the longest possible expiry in this scenario, there could be sites that have to renew the same day the outage starts).
The ACME client can implement multiple issuers and do some kind of load balancing or fallback between them, should one of them be inaccessible. Like Caddy does.
I get why for the browser guard, but why for this? If regular 90 day certificates are already working, then there is absolutely no reason that a 6 day one wouldn’t. Sure you might need to do some work on the backend to sort out the automation (though that is hopefully already being done with 90 day certs), but for the client side this should not matter whatsoever.
Let’s encrypt is great. HTTPS should not be reserved to companies which can afford to pay for certificates, which was what happened before, and it should not be difficult to set up, either. I don’t care what content you’re serving, plain HTTP (and others) should just not be used, it’s a big tracking and attack vector.
The article explained why they want to start offering 6-day certificates. It is because if your private key leaks then anyone can impersonate your site until the certificate expires, unless you revoke the certificate with the leaked key. And certificate revocation is not reliable.
I accept that certificate revocation is somewhat unreliable, but I will admit I am puzzled about just who it is that loses their private keys so frequently that they need a maximum of a 6-day period in which the leaked key could be used.
This is very bad for web openness and long term accessibility, much like the Rails browser version guard.
Why? Shorter expiry times don’t require any new browser support, 90 days certificates will continue to be available, shorter certs are opt-in, and other TLS certificate providers are available (even if your parameters are “free” and “supports ACME”).
It puts a lot more centralized dependency on LetsEncrypt. If your site has to get a new cert every 6 days and something happens to LE, your site is now unusable without intervention.
It’s not out of the realm of possibility that an attacker could force LE’s issuing/validating servers offline for 6 days (which is also the longest possible expiry in this scenario, there could be sites that have to renew the same day the outage starts).
That explains why it introduces potential fragility but not why 6 day certs are bad for the open web and accessibility.
The ACME client can implement multiple issuers and do some kind of load balancing or fallback between them, should one of them be inaccessible. Like Caddy does.
I get why for the browser guard, but why for this? If regular 90 day certificates are already working, then there is absolutely no reason that a 6 day one wouldn’t. Sure you might need to do some work on the backend to sort out the automation (though that is hopefully already being done with 90 day certs), but for the client side this should not matter whatsoever.
Let’s encrypt is great. HTTPS should not be reserved to companies which can afford to pay for certificates, which was what happened before, and it should not be difficult to set up, either. I don’t care what content you’re serving, plain HTTP (and others) should just not be used, it’s a big tracking and attack vector.
The article explained why they want to start offering 6-day certificates. It is because if your private key leaks then anyone can impersonate your site until the certificate expires, unless you revoke the certificate with the leaked key. And certificate revocation is not reliable.
I accept that certificate revocation is somewhat unreliable, but I will admit I am puzzled about just who it is that loses their private keys so frequently that they need a maximum of a 6-day period in which the leaked key could be used.
I don’t get how “so frequently” comes into it. If you loose your key very very rarely, you don’t care about for how long it could be misused?
Any individual doesn’t, but the whole web does. And if let’s encrypt loses trust, then the whole web suffers.
One key is one key/site which is 100s of millions of keys. Those 100s of millions of keys do pose a risk to trusting let’s encrypt on the whole.
You only need to lose your private keys once for the validity duration to matter.
Unless you consider less than a year (the longest expiration in typical use, AFAIK) to be “long term”, I don’t get your point.
previous discussions of the plans to offer this: https://lobste.rs/s/nnuufh/let_s_encrypt_will_begin_offering_6_day and https://lobste.rs/s/7sjhpm/announcing_six_day_ip_address
The post only mentioned lego, it looks like Certbot doesn’t support this yet: