Re: [pbs-devel] [PATCH proxmox{, -backup} 0/2] fix #6939: acme: support servers returning 204 for nonce requests

[Samuel Rufinatscha <s.rufinatscha@proxmox.com>]

On 10/29/25 8:50 AM, Thomas Lamprecht wrote:
> Thanks for the patch and actually also checking if PVE is affected, and why
> it isn't.
> 
> Am 28.10.25 um 20:34 schrieb Samuel Rufinatscha:
>> 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?
> 
> There probably isn't answer that strictly right in all cases, but in
> general it's good to have similar behavior across implementations,
> especially given that we do not know of any report where the PVE behavior
> of accepting all 2xx response codes caused any problems, from that 3.
> would be best, or does the RFC forbid the server to accept other status
> codes?
> 
> That said, in practice only 201 (Created) might make sense for ACME in
> addition to the referenced 200 (OK) and 204 (No Content), and following
> the RFC is fine, so 1. is IMO also a good solution here.
> Please note the difference to PVE in the commit message, there you write
> that behavior is now aligned with PVE, but it's rather "closer aligned"
> to, not fully.

According to RFC 8555, most ACME endpoints define exact expected status
codes. The only case where multiple 2xx codes are explicitly allowed is the
newNonce endpoint, where the RFC states that the server SHOULD return 
200 for
HEAD and MUST return 204 for GET.

I further looked into the Perl client and found that it enforces specific
codes for most endpoints as well, but performs a GET request [1] for nonce
retrieval (instead of HEAD) and accepts any 2xx success [2] code in that
case. So the behavior isn’t directly comparable to the Rust client, but it’s
worth noting. Functionally, this shouldn’t be an issue, as ACME 
providers are
required to support both methods, with HEAD being the preferred one.

I will update the commit messages and cover letter accordingly.

[1] 
https://git.proxmox.com/?p=proxmox-acme.git;a=blob;f=src/PVE/ACME.pm;h=f1e9bb7d316e3cea1e376c610b0479119217aecc;hb=HEAD#l219
[2] 
https://git.proxmox.com/?p=proxmox-acme.git;a=blob;f=src/PVE/ACME.pm;h=f1e9bb7d316e3cea1e376c610b0479119217aecc;hb=HEAD#l597



_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel