From: Manuel Federanko <m.federanko@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>, pbs-devel@lists.proxmox.com
Subject: Re: applied: [PATCH proxmox-backup v2] acme: partially fix #6372: scale certificate renewal checks by lifetime
Date: Mon, 27 Apr 2026 09:40:25 +0200 [thread overview]
Message-ID: <a17eb632-b027-4ef5-af05-af691a7d0207@proxmox.com> (raw)
In-Reply-To: <177704915730.3062357.10095633763040460247.b4-ty@b4>
On 2026-04-24 6:51 PM, Thomas Lamprecht wrote:
> On Thu, 23 Apr 2026 15:46:08 +0200, Manuel Federanko wrote:
>> Start renewing a certificate once 2/3 or 1/2 (for short-lived
>> certificates) of its total lifetime have passed, instead of the
>> hardcoded 30 days. This stays consistent with many certificates, which
>> are valid for 90 days and is recommended by letsencrypt [1].
>>
>> The update service runs daily, impose a 3 day minimum remaining lifetime
>> to still be able to handle transient failures for certificate renewals.
>>
>> [...]
>
> Just again for the record: v1 was already applied when v2 landed, to avoid
> dropping v2, I pulled its improvements in as follow-ups on top of v1, so
> this should be basically (semantically) applied now too.
>
> Follow-ups on top of v1 I pushed:
>
> - 3ee7129c6 acme: certificates: update stale 30-day doc comments
> - 034652107 acme: certificates: warn on fallback to 30-day renewal lead time
> - cec290d10 acme: certificates: parse certificate once per renewal check
> - 3d819b132 acme: certificates: factor out SECONDS_PER_DAY constant
>
> Ported from v2:
>
> - 74bc33071 acme: certificates: use 1/2 lifetime lead for short-lived certs
>
> I kept the 3-day floor inside cert_renew_lead_time rather than moving it to
> the daily-update caller as you did - behavior is equivalent for every
> lifetime, and it keeps the policy in one place with fewer cert reads per
> cycle.
thanks
> For the PDM port: the same improvements apply there too. One option would be
> to add a renewal_lead_time(&self) -> i64 helper on CertificateInfo in
> proxmox-acme-api::certificate_helpers, use it from PDM, and then switch PBS
> over to it here as well - single source of truth for both products.
yes, that makes sense
prev parent reply other threads:[~2026-04-27 7:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-23 13:46 [PATCH proxmox-backup v2] acme: partially fix #6372: scale certificate renewal checks by lifetime Manuel Federanko
2026-04-24 8:37 ` Fabian Grünbichler
2026-04-24 10:37 ` Thomas Lamprecht
2026-04-24 10:50 ` Thomas Lamprecht
2026-04-24 11:11 ` Fabian Grünbichler
2026-04-24 11:40 ` Manuel Federanko
2026-04-24 16:49 ` applied: " Thomas Lamprecht
2026-04-27 7:40 ` Manuel Federanko [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a17eb632-b027-4ef5-af05-af691a7d0207@proxmox.com \
--to=m.federanko@proxmox.com \
--cc=pbs-devel@lists.proxmox.com \
--cc=t.lamprecht@proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.