all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: pbs-devel@lists.proxmox.com, Manuel Federanko <m.federanko@proxmox.com>
Subject: applied: [PATCH proxmox-backup v2] acme: partially fix #6372: scale certificate renewal checks by lifetime
Date: Fri, 24 Apr 2026 18:49:16 +0200	[thread overview]
Message-ID: <177704915730.3062357.10095633763040460247.b4-ty@b4> (raw)
In-Reply-To: <20260423134607.105229-2-m.federanko@proxmox.com>

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.

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.




  parent reply	other threads:[~2026-04-24 16:53 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 ` Thomas Lamprecht [this message]
2026-04-27  7:40   ` applied: " Manuel Federanko

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=177704915730.3062357.10095633763040460247.b4-ty@b4 \
    --to=t.lamprecht@proxmox.com \
    --cc=m.federanko@proxmox.com \
    --cc=pbs-devel@lists.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.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal