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 DF8D31FF0E5 for ; Wed, 29 Jul 2026 11:53:28 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 53C5420AF5; Wed, 29 Jul 2026 11:53:28 +0200 (CEST) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 29 Jul 2026 11:53:07 +0200 Message-Id: Subject: Re: [PATCH proxmox 01/11] acme-api: make self-signed certificate expiry configurable To: "Lukas Wagner" , X-Mailer: aerc 0.20.0 References: <20260618115443.48618-1-s.sterz@proxmox.com> <20260618115443.48618-2-s.sterz@proxmox.com> In-Reply-To: From: "Shannon Sterz" X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1785318749399 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.159 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: C4T3TZLKPGPD3FCCJETFF6SN34YTWBV5 X-Message-ID-Hash: C4T3TZLKPGPD3FCCJETFF6SN34YTWBV5 X-MailFrom: s.sterz@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 Fri Jul 10, 2026 at 1:15 PM CEST, Lukas Wagner wrote: > Hi Shannon, > > thanks for the patch. Some notes inline. Thanks for the review! > > On Thu Jun 18, 2026 at 1:54 PM CEST, Shannon Sterz wrote: >> and change the default from 365000 days (almost 1000 years) to 3650 >> days (almost 10 years). almost 1000 years is excessive, as no >> practical cryptographic key can reasonably be considered safe for that >> amount of time. almost 10 years should still give plenty of time to >> prepare for certificate changes. >> >> Signed-off-by: Shannon Sterz >> --- >> >> Notes: >> imo, we could go down even more. as far as i am aware there is no re= al >> limit that is being enforced here for self-signed certificates from = a >> browser perspective. they are already trusted on an exemption-basis >> anyway. however, certificates signed by public CAs will only be vali= d >> for a maximum of 47 days by 2029 [1]. >> >> hence, i would personally either adopt the same limit or go down to = a >> year, as a sensible middle-ground. certificate rotation should reall= y >> be automated even in self-signed scenarios. we also had cases in the >> past, where customers already ran into issue because they wanted to >> limit the lifetime of their certificates below 30 days [2]. meaning >> that there is a need out there for shorter lived certificates (thoug= h, >> in that case a custom CA & ACME setup was used). >> >> [1]: https://github.com/cabforum/servercert/pull/553 >> [2]: https://bugzilla.proxmox.com/show_bug.cgi?id=3D6372 >> >> proxmox-acme-api/src/certificate_helpers.rs | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/proxmox-acme-api/src/certificate_helpers.rs b/proxmox-acme-= api/src/certificate_helpers.rs >> index 3921b18e..9c55d30e 100644 >> --- a/proxmox-acme-api/src/certificate_helpers.rs >> +++ b/proxmox-acme-api/src/certificate_helpers.rs > > Please use this opportunity to add a doc-string for this function which > also documents this new parameter. done. >> @@ -214,6 +214,7 @@ pub fn create_self_signed_cert( >> product_name: &str, >> nodename: &str, >> domain: Option<&str>, >> + expire: Option, > > Maybe change the name in such a way that it's clear that this is > - a duration (not a timestamp) > - measured in days > > e.g. `expiry_in_days` (there might be better choices) > > Maybe it would even be a good idea to use the 'Duration' type here? I > guess then the name could stay the same, since the type encodes the > semantics quite nicely. > > Duration::from_days is still only in nightly, so instantiating it via > Duration::from_secs for now is a bit awkward for this situation, > admittedly. > > https://doc.rust-lang.org/beta/std/time/struct.Duration.html#method.from_= days i went with `days_valid` for now as it's a little shorter and conveys the meaning appropriately in my opinion. >> ) -> Result<(PKey, X509), Error> { >> let rsa =3D Rsa::generate(4096).unwrap(); >> >> @@ -223,7 +224,7 @@ pub fn create_self_signed_cert( >> >> let today =3D openssl::asn1::Asn1Time::days_from_now(0)?; >> x509.set_not_before(&today)?; >> - let expire =3D openssl::asn1::Asn1Time::days_from_now(365 * 1000)?; >> + let expire =3D openssl::asn1::Asn1Time::days_from_now(expire.unwrap= _or(365 * 10))?; >> x509.set_not_after(&expire)?; >> >> let mut fqdn =3D nodename.to_owned(); > > > Also would not hurt to use this opportunity to implement a simple > unit-test for this function, which (at least) tests that the expiry is > set correctly. I think this crate should already have all the needed > helpers to parse and verify the generated cert in a test? ack, added three unit tests that should cover the four different scenarios of input parameters (product_name and nodename only; product_name, nodename and domain; product_name, nodename and days_valid; product_name, nodename, domain and days_valid).