From: "Lukas Wagner" <l.wagner@proxmox.com>
To: "Shannon Sterz" <s.sterz@proxmox.com>, <pdm-devel@lists.proxmox.com>
Subject: Re: [PATCH proxmox 01/11] acme-api: make self-signed certificate expiry configurable
Date: Fri, 10 Jul 2026 13:15:47 +0200 [thread overview]
Message-ID: <DJUUJUK8M08T.A77N2H8CJYU4@proxmox.com> (raw)
In-Reply-To: <20260618115443.48618-2-s.sterz@proxmox.com>
Hi Shannon,
thanks for the patch. Some notes inline.
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 <s.sterz@proxmox.com>
> ---
>
> Notes:
> imo, we could go down even more. as far as i am aware there is no real
> 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 valid
> 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 really
> 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 (though,
> 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=6372
>
> 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.
> @@ -214,6 +214,7 @@ pub fn create_self_signed_cert(
> product_name: &str,
> nodename: &str,
> domain: Option<&str>,
> + expire: Option<u32>,
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
> ) -> Result<(PKey<Private>, X509), Error> {
> let rsa = Rsa::generate(4096).unwrap();
>
> @@ -223,7 +224,7 @@ pub fn create_self_signed_cert(
>
> let today = openssl::asn1::Asn1Time::days_from_now(0)?;
> x509.set_not_before(&today)?;
> - let expire = openssl::asn1::Asn1Time::days_from_now(365 * 1000)?;
> + let expire = openssl::asn1::Asn1Time::days_from_now(expire.unwrap_or(365 * 10))?;
> x509.set_not_after(&expire)?;
>
> let mut fqdn = 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?
next prev parent reply other threads:[~2026-07-10 11:15 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-18 11:54 [PATCH datacenter-manager/proxmox{,-backup} 00/11] TLS Certificate Rotation Shannon Sterz
2026-06-18 11:54 ` [PATCH proxmox 01/11] acme-api: make self-signed certificate expiry configurable Shannon Sterz
2026-07-10 11:15 ` Lukas Wagner [this message]
2026-06-18 11:54 ` [PATCH proxmox-backup 02/11] config: use proxmox_acme_api for generating self-signed certificates Shannon Sterz
2026-06-18 11:54 ` [PATCH proxmox-backup 03/11] config: adapt to api change in proxmox_acme_api, add expiry paramter Shannon Sterz
2026-06-18 11:54 ` [PATCH proxmox-backup 04/11] config/server/api: add certificate renewal logic including notifications Shannon Sterz
2026-07-10 11:17 ` Lukas Wagner
2026-06-18 11:54 ` [PATCH proxmox-backup 05/11] daily-update/docs: warn on excessive self-signed certificate lifetime Shannon Sterz
2026-07-10 11:17 ` Lukas Wagner
2026-06-18 11:54 ` [PATCH proxmox-backup 06/11] backup-manager cli: `cert update` can create auth and csrf key Shannon Sterz
2026-06-18 11:54 ` [PATCH datacenter-manager 07/11] certs: adapt to api change in proxmox_acme_api, add expiry paramter Shannon Sterz
2026-06-18 11:54 ` [PATCH datacenter-manager 08/11] api/auth/bin: add certificate renewal logic Shannon Sterz
2026-07-10 11:17 ` Lukas Wagner
2026-06-18 11:54 ` [PATCH datacenter-manager 09/11] cli: expose certificate management endpoints via the cli Shannon Sterz
2026-06-18 11:54 ` [PATCH datacenter-manager 10/11] daily-update/docs: warn on excessive tls certificate validity periods Shannon Sterz
2026-06-18 11:54 ` [PATCH datacenter-manager 11/11] docs/certificates: use correct certificate file name Shannon Sterz
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=DJUUJUK8M08T.A77N2H8CJYU4@proxmox.com \
--to=l.wagner@proxmox.com \
--cc=pdm-devel@lists.proxmox.com \
--cc=s.sterz@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox