3 ms·

HPKP uses public keys and AFAIK it rotates them by default every 90 days (unless you explicitly said no). HPKP and Let's encrypt has been a notable problem on

HPKP uses public keys and AFAIK it rotates them by default every 90 days (unless you explicitly said no). HPKP and Let's encrypt has been a notable problem on the Let's encrypt community, if you see my reply to an earlier comment you can read the links on the problem it brings, it has even been proposed to use long-term certs (https://github.com/certbot/certbot/issues/2083 https://github.com/certbot/certbot/issues/2083) but the devs didn't like it therefore since it's not recommended and encouraged by one of the major free ssl certificate authorities it just means that it will less people will implement it and browser will eventually cut the support.

throw2016 9y ago
Why this high handed approach by the letsencrypt team? This completely arbitrary 90 day limit makes little sense when the world has been using 1 and 3 year certs without issue. This seems to be very little justification for it apart from questionable security assumptions that will not stand up to scrutiny. Are they suggesting sites not using letsencrypt are insecure? Why make assumptions in the first place about day to day server security when you are in the business of issuing certificates? This just reflects a patronizing attitude that places constraints on others because of individual preferences. If they want to advocate 90 day renewals a more reasonable approach is a separate team to provide tools and advocate 90 days renewals.
- pfg 9y ago
  First, it's worth pointing out that certificate lifetime is tangential to HPKP. HPKP is public key-based, and nothing prevents you from using the same public key for years. > This completely arbitrary 90 day limit makes little sense when the world has been using 1 years, 3 year certs without issue. Browsers vendors (most notably Google and Mozilla) have been pushing for shorter certificate lifetimes for years. 3-year certificates have been banned starting with March 2018 (the new limit being something like 2 years and 2 months). Google itself has settled on 90-day certificates for most of their web properties, and they continue to push for shorter lifetimes in the CA/B Forum and might very well start enforcing it through their own root policy if no consensus is reached. > This seems to be very little justification for it apart from questionable security assumptions that will not stand up to scrutiny. Are they suggesting sites not using lets encrypt are insecure? [citation needed]. For a long discussion on the pros and cons, see [1]. > Why make assumptions in the first place about day to day server security when you are in the business of issuing certificates? One thing to keep in mind is that Let's Encrypt is in the business of creating a more secure and privacy-respecting Web. Naturally, it would be silly to focus solely on those two things if you actually want anyone to use your product, but if the cost of picking the more secure option isn't too high, I wouldn't expect them to go for the perhaps slightly easier option, especially given that automation is another one of their goals and the issues are mostly with manual processes. [1]: https://community.letsencrypt.org/t/pros-and-cons-of-90-day-certificate-lifetimes/4621?u=pfg https://community.letsencrypt.org/t/pros-and-cons-of-90-day-...
  - apple4ever 9y ago
    > One thing to keep in mind is that Let's Encrypt is in the business of creating a more secure and privacy-respecting Web. And their required short certificates go against that philosophy. Allowing short ones is fine. Requiring it is dumb. And that discussion had very little good pros. I feel the short certificate discussion nicely mirrors the short password discussion- both short proponents have little good arguments on their site.
- apple4ever 9y ago
  Its absolutely mind boggling they REQUIRE 90 days. Offering is great, encouraging it is fine, but requiring it is dumb. It actually goes against their stated policy of encrypting the entire Internet, because it makes it so much harder or riskier to keep the certificate up to date (yes, even with automation).
pfg 9y ago
Defaulting to key rotation for each renewal is a sane choice for most ACME clients. There is no enforcement of this on the CA side of things, so HPKP deployment is possible regardless. The vast majority of sites should probably not use HPKP. Those sites will benefit from key rotation, and defaulting to anything else would make them less secure in a Heartbleed-like event. Client support for opting out of key rotation is a different matter. Many clients already offer this, just like certbot does with --csr, but that's very annoying to use. IIRC certbot has an open PR that adds key reuse support during renewal.

throw2016 9y ago

Why this high handed approach by the letsencrypt team? This completely arbitrary 90 day limit makes little sense when the world has been using 1 and 3 year certs without issue. This seems to be very little justification for it apart from questionable security assumptions that will not stand up to scrutiny. Are they suggesting sites not using letsencrypt are insecure? Why make assumptions in the first place about day to day server security when you are in the business of issuing certificates? This just reflects a patronizing attitude that places constraints on others because of individual preferences. If they want to advocate 90 day renewals a more reasonable approach is a separate team to provide tools and advocate 90 days renewals.

pfg 9y ago
First, it's worth pointing out that certificate lifetime is tangential to HPKP. HPKP is public key-based, and nothing prevents you from using the same public key for years. > This completely arbitrary 90 day limit makes little sense when the world has been using 1 years, 3 year certs without issue. Browsers vendors (most notably Google and Mozilla) have been pushing for shorter certificate lifetimes for years. 3-year certificates have been banned starting with March 2018 (the new limit being something like 2 years and 2 months). Google itself has settled on 90-day certificates for most of their web properties, and they continue to push for shorter lifetimes in the CA/B Forum and might very well start enforcing it through their own root policy if no consensus is reached. > This seems to be very little justification for it apart from questionable security assumptions that will not stand up to scrutiny. Are they suggesting sites not using lets encrypt are insecure? [citation needed]. For a long discussion on the pros and cons, see [1]. > Why make assumptions in the first place about day to day server security when you are in the business of issuing certificates? One thing to keep in mind is that Let's Encrypt is in the business of creating a more secure and privacy-respecting Web. Naturally, it would be silly to focus solely on those two things if you actually want anyone to use your product, but if the cost of picking the more secure option isn't too high, I wouldn't expect them to go for the perhaps slightly easier option, especially given that automation is another one of their goals and the issues are mostly with manual processes. [1]: https://community.letsencrypt.org/t/pros-and-cons-of-90-day-certificate-lifetimes/4621?u=pfg https://community.letsencrypt.org/t/pros-and-cons-of-90-day-...
- apple4ever 9y ago
  > One thing to keep in mind is that Let's Encrypt is in the business of creating a more secure and privacy-respecting Web. And their required short certificates go against that philosophy. Allowing short ones is fine. Requiring it is dumb. And that discussion had very little good pros. I feel the short certificate discussion nicely mirrors the short password discussion- both short proponents have little good arguments on their site.
apple4ever 9y ago
Its absolutely mind boggling they REQUIRE 90 days. Offering is great, encouraging it is fine, but requiring it is dumb. It actually goes against their stated policy of encrypting the entire Internet, because it makes it so much harder or riskier to keep the certificate up to date (yes, even with automation).

pfg 9y ago

Defaulting to key rotation for each renewal is a sane choice for most ACME clients. There is no enforcement of this on the CA side of things, so HPKP deployment is possible regardless. The vast majority of sites should probably not use HPKP. Those sites will benefit from key rotation, and defaulting to anything else would make them less secure in a Heartbleed-like event. Client support for opting out of key rotation is a different matter. Many clients already offer this, just like certbot does with --csr, but that's very annoying to use. IIRC certbot has an open PR that adds key reuse support during renewal.