On Tue, Oct 13, 2026 at 10:41 PM Santiago Rincón <[email protected]> wrote:
> > > If I understand well, the certbot in bookworm LTS is version 2, which > does not > > > support ARI (dynamic windows to resist to mass revocations). Even > trixie > > > certbot is not 4.1+. > > > > > > Even on bookworm, as certbot is started twice a day, and > > > > > > /etc/letsencrypt/renewal/XXX.ch.conf:# renew_before_expiry = 30 days > > > > > > it should work no problem in 2027 (64 days certificate lifetime, > > > reissuing recommended at 2/3 of certificate life) or even 2028 > > > (45 days, 2/3 is just 30 days). > > 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? 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, -- Harlan Lieberman-Berg ~hlieberman
