Dear Maintainer, our cert provider is issuing revocation certs for all of our/their certs, due to some mistake on their side. and in their support/incident email, they mention : "If your ACME client supports the ACME Renewal Information (ARI) extension, no action is needed as the certificates will be replaced automatically. This has already been tested successfully in the course of a recent mass-replacement event." so, if ARI support was present in certbot, we wouldn't really need to do anything manually, like re-issueing all certs...(if i understand ARI correctly). checking ARI support, it seems certbot v4.1.1 introduced it, and v4.2.0 applied some ARI-related fixes.. so, it'd be nice if we could have those changes in trixie... thanks in advance, d.
Hi, (adding #1142589, since it's related) El 13/10/26 a las 21:01, Bastien Roucaries escribió: I do agree that this should be first discussed for and tackled in trixie. Since this doesn't seem related to a vulnerability, I think trixie is mostly on the certbot maintainer domain. Harlan, any thoughts? Cheers,
Hi, (adding #1142589, since it's related) El 13/10/26 a las 21:01, Bastien Roucaries escribió: I do agree that this should be first discussed for and tackled in trixie. Since this doesn't seem related to a vulnerability, I think trixie is mostly on the certbot maintainer domain. Harlan, any thoughts? Cheers,
Hi Santiago, all, I just quickly looked back in the last couple of releases, and it looks like we had renewal defaults set as follows: - bullseye: 30 days, fixed - bookworm: 30 days, fixed - trixie: 2/3rds of total certificate lifetime, unless total certificate lifetime is less than 10 days, in which case 1/2 - forky/sid: ARI, or as in trixie In 2028, even bullseye (and, I think, most earlier versions -- the 30 days threshold has been around for a while, IIRC) should be OK in terms of the shortened lifetimes. The only real downside here for trixie users is that, with the shut down of the Let's Encrypt OCSP servers, the certbot client has no way to tell that its own certificate has been revoked by Let's Encrypt (and to renew immediately). CA initiated revocation is, by far, most commonly due to key exposure -- and in the situation that the key has been exposed, I'd argue that blind renewal is the wrong move anyway. I know that the edge case I'm hand waving away here is the exact situation that the original submitter was reporting happened to them -- and it would have helped in 2022 for Let's Encrypt -- but it's a very rare phenomenon. On balance, I'm not sure that doing a release of 5.5 through the stable-update process would meet the required "important severity" bar there. If the security folks (and stable release team) feel that the potential for DoS due to CA initiated revocation does meet the threshold, though, I'm happy to manage the backporting process to get it into s-p-u. Sincerely,
Hi Santiago, all, I just quickly looked back in the last couple of releases, and it looks like we had renewal defaults set as follows: - bullseye: 30 days, fixed - bookworm: 30 days, fixed - trixie: 2/3rds of total certificate lifetime, unless total certificate lifetime is less than 10 days, in which case 1/2 - forky/sid: ARI, or as in trixie In 2028, even bullseye (and, I think, most earlier versions -- the 30 days threshold has been around for a while, IIRC) should be OK in terms of the shortened lifetimes. The only real downside here for trixie users is that, with the shut down of the Let's Encrypt OCSP servers, the certbot client has no way to tell that its own certificate has been revoked by Let's Encrypt (and to renew immediately). CA initiated revocation is, by far, most commonly due to key exposure -- and in the situation that the key has been exposed, I'd argue that blind renewal is the wrong move anyway. I know that the edge case I'm hand waving away here is the exact situation that the original submitter was reporting happened to them -- and it would have helped in 2022 for Let's Encrypt -- but it's a very rare phenomenon. On balance, I'm not sure that doing a release of 5.5 through the stable-update process would meet the required "important severity" bar there. If the security folks (and stable release team) feel that the potential for DoS due to CA initiated revocation does meet the threshold, though, I'm happy to manage the backporting process to get it into s-p-u. Sincerely,
No, I think we're good with the current stack.
Cheers,
Moritz
No, I think we're good with the current stack.
Cheers,
Moritz