From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id BDF031FF0B7 for ; Fri, 16 Oct 2026 15:17:36 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 43F75213D2; Fri, 16 Oct 2026 15:17:34 +0200 (CEST) Message-ID: <906980c1-cf3e-40d4-8b91-4d76fb09266b@proxmox.com> Date: Fri, 16 Oct 2026 15:17:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH common/manager 0/2] fix #8006: acme: lifetime-based certificate renewal threshold To: =?UTF-8?Q?Michael_K=C3=B6ppl?= , pve-devel@lists.proxmox.com References: <20261006123120.68750-1-d.riley@proxmox.com> Content-Language: en-US From: David Riley In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1792156650915 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.745 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: Y3UJA4XWSRMWKMC6TGY65USTIZNJILWB X-Message-ID-Hash: Y3UJA4XWSRMWKMC6TGY65USTIZNJILWB X-MailFrom: d.riley@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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] > > > >