From: David Riley <d.riley@proxmox.com>
To: "Michael Köppl" <m.koeppl@proxmox.com>, pve-devel@lists.proxmox.com
Subject: Re: [PATCH common/manager 0/2] fix #8006: acme: lifetime-based certificate renewal threshold
Date: Fri, 16 Oct 2026 15:17:30 +0200 [thread overview]
Message-ID: <906980c1-cf3e-40d4-8b91-4d76fb09266b@proxmox.com> (raw)
In-Reply-To: <DM69TMFXYN1W.2E40T270K84T0@proxmox.com>
On 10/16/26 2:45 PM, Michael Köppl wrote:
> Tested this a bit using faketime to force certificate renewals. Noticed
> the following:
> - Could create a scenario where an expired short-lived cert would be
> served because of the missing 3-day floor present in PBS: with a 48h
> cert, the renewal window is 24h. With the clock moved to 23h after the
> cert was issued (25h left), renewal is refused with "does not expire
> within the next 1 days". At 49h after the cert was issued (1h after
> it expired), renew is no longer refused. The 2 attempts arre 26h
> apart, which is within the randomized time frame for pve-daily-update
> runs (01:00 + up to 5h delay), so it can happen that no run lands
> inside the window. The expired cert is then served until the next run
> renews it.
> - The pveupdate script still uses the hard-coded 30 days, so creating a
> certificate with 25 days left, it will attempt to renew, but the API
> will refuse.
> Added comments for the above on the individual patches.
>
> For longer-lived certs as describes in the cover letter, this worked as
> expected, though. I really like this as an improvement to PVE.
Thanks for taking the time to do a thorough review and testing it and pointing
out the edge cases that currently exist.
Seems like I have missed a couple of essential parts, I will address them in a v2.
>
> On Tue Oct 6, 2026 at 2:31 PM CEST, David Riley wrote:
>> This patch series addresses an issue where short-lived ACME
>> certificates (e.g., 31-day validity) trigger daily renewal attempts
>> due to PVE's hardcoded 30-day threshold.
>>
>> Because PVE currently relies on non-ARI renewal logic, these daily
>> attempts quickly exhaust upstream rate limits. With Let's Encrypt,
> [snip]
>
>
>
>
prev parent reply other threads:[~2026-10-16 13:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-06 12:31 [PATCH common/manager 0/2] fix #8006: acme: lifetime-based certificate renewal threshold David Riley
2026-10-06 12:31 ` [PATCH pve-common 1/2] certificate: add helpers for lifetime-based ACME renewal David Riley
2026-10-16 12:45 ` Michael Köppl
2026-10-16 13:17 ` David Riley
2026-10-06 12:31 ` [PATCH pve-manager 2/2] fix #8006: api: acme: lifetime-based certificate renewal threshold David Riley
2026-10-16 12:45 ` Michael Köppl
2026-10-16 13:17 ` David Riley
2026-10-16 12:45 ` [PATCH common/manager 0/2] fix #8006: " Michael Köppl
2026-10-16 13:17 ` David Riley [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=906980c1-cf3e-40d4-8b91-4d76fb09266b@proxmox.com \
--to=d.riley@proxmox.com \
--cc=m.koeppl@proxmox.com \
--cc=pve-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.