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 E197D1FF129 for ; Thu, 06 Aug 2026 17:23:22 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 7C11621375; Thu, 06 Aug 2026 17:23:22 +0200 (CEST) From: =?UTF-8?q?Fabian=20Gr=C3=BCnbichler?= To: pdm-devel@lists.proxmox.com, Shannon Sterz Subject: partially-applied [PATCH cluster/common/datacenter-manager/manager/proxmox v2 00/16] TLS Certificate Staging Date: Thu, 6 Aug 2026 17:23:01 +0200 Message-ID: <178602971412.1142988.5813047335524675197.b4-ty@proxmox.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260805131838.254723-2-s.sterz@proxmox.com> References: <20260805131838.254723-2-s.sterz@proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1786029783315 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.096 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_LOW -0.7 Sender listed at https://www.dnswl.org/, low 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: 43PZQ23FZHLLH7YSAXTB2FFCPGIJLMEQ X-Message-ID-Hash: 43PZQ23FZHLLH7YSAXTB2FFCPGIJLMEQ X-MailFrom: f.gruenbichler@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 Datacenter Manager development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Wed, 05 Aug 2026 15:18:23 +0200, Shannon Sterz wrote: > the aim of this series is to allow clients to automatically adapt to regular > certificate rotation. the top-level overview of the mechanism proposed here is > as follows: > > - hosts that rotate their certificate create a new certificate at the earliest > four weeks before their current certificate expires. this certificate is > considered as "staged" up until it becomes actively used. > - clients can query a host for a staged certificate at any moment, the host > will provide information such as the fingerprint for the active and staged > certificate(s). > - at the earliest two weeks before their current certificate expires, hosts may > start using the "staged" certificate. the two week window is needed to give > clients enough time to query a potential staged certificate. > - clients, that use fingerprints to validate a TLS certificate, should discard > the previously used fingerprint and update to the new certificate's > fingerprint (the previously staged certificate) as soon as they detect its > usage. connections trying to authenticate themselves with the old certificate > should be rejected at this point. > > [...] Applied this one, thanks! [13/16] server: remotes: lock remotes config when updating it commit: f157678707b86c486f47bd4992ae7eed717ecd42 Best regards, -- Fabian Grünbichler