From: Samuel Rufinatscha <s.rufinatscha@proxmox.com>
To: pbs-devel@lists.proxmox.com
Subject: [pbs-devel] superseded: [PATCH proxmox{, -backup} 0/2] fix #6939: acme: support servers returning 204 for nonce requests
Date: Wed, 29 Oct 2025 17:49:50 +0100 [thread overview]
Message-ID: <73f48ddb-71cf-4b58-81c5-430ab41a4013@proxmox.com> (raw)
In-Reply-To: <20251028152201.216603-1-s.rufinatscha@proxmox.com>
https://lore.proxmox.com/pbs-devel/20251029164520.263926-1-s.rufinatscha@proxmox.com/T/#t
On 10/28/25 4:21 PM, Samuel Rufinatscha wrote:
> Hi,
>
> this series proposes a change to ACME account registration in Proxmox
> Backup Server (PBS), so that it also works with ACME servers that return
> HTTP 204 No Content to the HEAD request for newNonce.
>
> This behaviour was observed against a specific ACME deployment and
> reported as bug #6939 [1]. Currently, PBS cannot register an ACME
> account for this CA.
>
> ## Problem
>
> During ACME account registration, PBS first fetches an anti-replay nonce
> by sending a HEAD request to the CA’s newNonce URL. RFC 8555 7.2 [2]
> says:
>
> * the server MUST include a Replay-Nonce header with a fresh nonce,
> * the server SHOULD use status 200 OK for the HEAD request,
> * the server MUST also handle GET on the same resource with status 204 No
> Content and an empty body [2].
>
> Currently, our Rust ACME clients only accept 200 OK. PBS inherits that
> strictness and aborts with:
>
> *ACME server responded with unexpected status code: 204*
>
> This is also stricter than the PVE Perl ACME client, which tolerates any
> 2xx success codes [3]. The author mentions, the issue did not appear
> with PVE9 [1].
>
> ## Ideas to solve the problem
>
> To support ACME providers which return 204 No Content, the underlying
> ACME clients need to tolerate both 200 OK and 204 No Content as valid
> responses for the nonce HEAD request, as long as the Replay-Nonce is
> provided.
>
> I considered following solutions:
>
> 1. Change the `expected` field of the `AcmeRequest` type from `u16` to
> `Vec<u16>`, to support multiple success codes
>
> 2. Keep `expected: u16` and add a second field e.g. `expected_other:
> Vec<u16>` for "also allowed" codes.
>
> 3. Support any 2xx success codes, and remove the `expected` check
>
> I thought (1) might be reasonable, because:
>
> * It stays explicit and makes it clear which statuses are considered
> success.
> * We don’t create two parallel concepts ("expected" vs
> "expected_other") which introduces additional complexity
> * Can be extend later if we meet yet another harmless but not 200
> variant.
> * We don’t allow arbitrary 2xx.
>
> What do you think? Do you maybe have any other solution in mind that
> would fit better?
>
> ## Testing
>
> To prove the proposed fix, I reproduced the scenario:
>
> Pebble (release 2.8.0) from Let's Encrypt [5] running on a Debian 9 VM
> as the ACME server. nginx in front of Pebble, to intercept the
> `newNonce` request in order to return 204 No Content instead of 200 OK,
> all other requests are unchanged and forwarded to Pebble. Trust the
> Pebble and ngix CAs via `/usr/local/share/ca-certificates` +
> `update-ca-certificates` on the PBS VM.
>
> Then I ran following command against nginx:
>
> ```
> proxmox-backup-manager acme account register proxytest root@backup.local
> --directory 'https://nginx-address/dir
>
> Attempting to fetch Terms of
> Service from "https://acme-vm/dir"
> Terms of Service:
> data:text/plain,Do%20what%20thou%20wilt
> Do you agree to the above terms?
> [y|N]: y
> Do you want to use external account binding? [y|N]: N
> Attempting
> to register account with "https://acme-vm/dir"...
> Registration
> successful, account URL: https://acme-vm/my-account/160e58b66bdd72da
> ```
>
> When adjusting the nginx configuration to return any other non-expected
> success status code, e.g. 205, PBS expectely rejects with `API
> misbehaved: ACME server responded with unexpected status code: 205`.
>
> ## Maintainer notes:
>
> The patch series involves the following components:
>
> proxmox-acme: Apply PATCH 1 to change `expected` from `u16` to
> `Vec<u16>`. This results in a breaking change, as it changes the public
> API of the `AcmeRequest` type that is used by other components.
>
> proxmox-acme-api: Needs to depend on the new proxmox-acme; patch bump
>
> proxmox-backup: Apply PATCH 2 to use the new API changes; no breaking
> change as of only internal changes; patch bump
>
> proxmox-perl-rs / proxmox-datacenter-manager: Will need to use the
> dependency version bumps to follow the new proxmox-acme.
>
> ## Patch summary
>
> [PATCH 1/2] fix #6939: support providers returning 204 for nonce
> requests
>
> * Make the expected-status logic accept multiple allowed codes.
> * Treat both 200 OK and 204 No Content as valid for HEAD /newNonce,
> provided Replay-Nonce is present.
> * Keep rejecting other codes.
>
> [PATCH 2/2] acme: accept HTTP 204 from newNonce endpoint
>
> * Use the updated proxmox-acme behavior in PBS.
> * PBS can now register an ACME account against servers that return 204
> for the nonce HEAD request.
> * Still rejects unexpected codes.
>
> Thanks for considering this patch series, I look forward to your
> feedback.
>
> Best,
> Samuel Rufinatscha
>
> [1] Bugzilla report #6939:
> [https://bugzilla.proxmox.com/show_bug.cgi?id=6939](https://bugzilla.proxmox.com/show_bug.cgi?id=6939)
> [2] RFC 8555 (ACME):
> [https://datatracker.ietf.org/doc/html/rfc8555/#section-7.2](https://datatracker.ietf.org/doc/html/rfc8555/#section-7.2)
> [3] PVE’s Perl ACME client:
> [https://git.proxmox.com/?p=proxmox-acme.git;a=blob;f=src/PVE/ACME.pm;h=f1e9bb7d316e3cea1e376c610b0479119217aecc;hb=HEAD#l597](https://git.proxmox.com/?p=proxmox-acme.git;a=blob;f=src/PVE/ACME.pm;h=f1e9bb7d316e3cea1e376c610b0479119217aecc;hb=HEAD#l597)
> [4] Pebble ACME server:
> [https://github.com/letsencrypt/pebble](https://github.com/letsencrypt/pebble)
>
> proxmox:
>
> Samuel Rufinatscha (1):
> fix #6939: acme: support servers returning 204 for nonce requests
>
> proxmox-acme/src/account.rs | 10 +++++-----
> proxmox-acme/src/async_client.rs | 6 +++---
> proxmox-acme/src/client.rs | 2 +-
> proxmox-acme/src/request.rs | 4 ++--
> 4 files changed, 11 insertions(+), 11 deletions(-)
>
>
> proxmox-backup:
>
> Samuel Rufinatscha (1):
> fix #6939: acme: accept HTTP 204 from newNonce endpoint
>
> src/acme/client.rs | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
>
> Summary over all repositories:
> 5 files changed, 14 insertions(+), 14 deletions(-)
>
_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel
prev parent reply other threads:[~2025-10-29 16:49 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-28 15:21 [pbs-devel] " Samuel Rufinatscha
2025-10-28 15:22 ` [pbs-devel] [PATCH proxmox 1/1] " Samuel Rufinatscha
2025-10-29 7:23 ` Christian Ebner
2025-10-29 7:53 ` Thomas Lamprecht
2025-10-29 8:07 ` Christian Ebner
2025-10-29 10:36 ` Wolfgang Bumiller
2025-10-29 11:27 ` Thomas Lamprecht
2025-10-29 15:50 ` Samuel Rufinatscha
2025-10-29 10:38 ` Wolfgang Bumiller
2025-10-29 15:56 ` Samuel Rufinatscha
2025-10-28 15:22 ` [pbs-devel] [PATCH proxmox-backup 1/1] fix #6939: acme: accept HTTP 204 from newNonce endpoint Samuel Rufinatscha
2025-10-29 7:51 ` [pbs-devel] [PATCH proxmox{, -backup} 0/2] fix #6939: acme: support servers returning 204 for nonce requests Thomas Lamprecht
2025-10-29 16:02 ` Samuel Rufinatscha
2025-10-29 16:49 ` Samuel Rufinatscha [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=73f48ddb-71cf-4b58-81c5-430ab41a4013@proxmox.com \
--to=s.rufinatscha@proxmox.com \
--cc=pbs-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox