This report is for the package app-crypt/certbot. Let's Encrypt is switching to short-lived certificates in an attempt to manage revocations more efficiently.[0,1] The thinking is, by ensuring the certificate expires quickly, relying parties will have less reliance on revocations lists in case a CA is compromised. The problem is practice is, certbot generates a new key pair by default when renewing a certificate. The new key pair breaks key continuity schemes. Key continuity, like public key pinning, provide better security properties than gratuitous key rotations.[2] Pinning a public key means relying parties no longer need to rely on trust. ("Trust" is what to use when there are no security controls to place, like public key pinning). This problem has always existed, but it seems like it is going to become more acute based on a 6-day lifetime. Asking users who practice pinning to update their pinsets every 6 days is excessive. It creates an undue burden on those folks who want the higher assurances provided by pinning. The issue has been raised with folks on Mozilla's dev-security-policy mailing list.[3,4] The CA's appear less concerned about collateral damage, like breaking key continuity schemes. (Short-lived certificates and key continuity can coexist, but it takes care when selecting default configurations for tools like certbot). According to discussions on Mozilla's dev-security-policy mailing list, CAs maintain a blacklist of compromised keys. Additionally, a public database of compromised key pairs is available.[5,6] In both cases, CAs can refuse to issue a certificate based on a known compromised key. Please consider adding the `reuse-key = True` option to certbot's ini file to promote key continuity. Or, in case certbot is being invoked via the command line, then use the `--reuse-key` option to promote key continuity. [0] A Note from our Executive Director, <https://letsencrypt.org/2024/12/11/eoy-letter-2024/> [1] Short-Lived Certificates Coming to Let’s Encrypt, <https://www.schneier.com/blog/archives/2024/12/short-lived-certificates-coming-to-lets-encrypt.html> [2] Engineering Security, Key Continuity Management, <https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf>, pp. 375-384 [3] Concerns about very-short-lived certificates, <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/_335unOyteQ/m/3lddQBXgBAAJ> [4] Let's Encrypt New Intermediate Certificates, <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/L7XoAXt_s1c/m/k_vdk9rQAwAJ> [5] The Pwnedkeys Revokinator is back!, <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/Ktb2knJUQ20/m/IbUkTLBFBwAJ> [6] Certificate with compromised key / *.digicert-demo.com, <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/d21mtDJ7YXQ/m/YF2of9RwDAAJ>
We don't currently ship a modified .ini file or anything like that for certbot. I'm not sure if we want to do this unilaterally -- what are other distributions considering? If you've filed tickets with them, please link them here too.
(In reply to Sam James from comment #1) > We don't currently ship a modified .ini file or anything like that for > certbot. > > I'm not sure if we want to do this unilaterally -- what are other > distributions considering? If you've filed tickets with them, please link > them here too. Thanks Sam. I have bug reports for Debian, Gentoo and Red Hat (Fedora) at the moment. I'm waiting to be approved for the Arch Linux bug tracker. Once I have the Arch Linux bug filed, I'll add a comment with all the reports (and urls). Are there other distros you suggest reporting to?
