ACME allow certificate revocation with other reasons than 0

[Daniel-Nashed]

Current challenge

The HCL Domino ACME client always specifies a reason (1 to 4).
There is currently no way to not pass a reason on Domino side. There is always reason 1 or 4 passed.

HashiCorp ACME returns an error in this case and it looks like the error is what is currently intended.

Error text returned via ACME protocol:

Vault does not support revocation reasons (got 1; expected omitted or 0/unspecified): The revocation reason provided is not allowed by the server

Expected behavior
Support the RFC compliant other revocation reasons.

Acceptable workaround
Ignore revocation reason and assume 0 even another reason is specified.

Maybe there is a way to configure the ACME endpoint to allow other reason codes?

Environment

Latest Container Image: Vault v1.21.4, built 2026-03-04T17:40:05Z

[dosubot]

This is indeed a current limitation in Vault's ACME implementation. The rejection happens in acmeRevocationHandler in path_acme_revoke.go, which explicitly rejects any non-zero reason code:

if int(reason) != 0 {
    return nil, fmt.Errorf("Vault does not support revocation reasons (got %v; expected omitted or 0/unspecified): %w", int(reason), ErrBadRevocationReason)
}

There is no configuration option to change this behavior — the ACME config struct has no field for revocation reason policy. This has been the case since the ACME revocation handler was first introduced in April 2023 (PR #20340).

While Vault's behavior is technically RFC 8555-compliant (Section 7.6 allows servers to reject unsupported reason codes via badRevocationReason), it's more restrictive than necessary and breaks compatibility with clients like HCL Domino that always send a reason code.

I didn't find any existing issues or PRs tracking this, so this appears to be the first request for it. A reasonable fix could be to accept valid RFC reason codes (1–10) and simply treat them as 0/unspecified internally, since Vault's broader PKI engine (including OCSP responses) consistently uses Unspecified for all revocations anyway [1]. This would provide your "acceptable workaround" without requiring Vault to fully propagate reason codes through CRLs/OCSP.

@heatherezell will escalate this to engineering for evaluation.

Written by @dosu, edited by heatherezell

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

  

[Daniel-Nashed]

Thanks for looking at it. Handling a valid reason as 0 would perfectly OK as a solution.
I don't see there needs to be an extra setting for this changed behavior.