[Bug]: ACME server does not enforce termsOfServiceAgreed when termsOfService is configured

[vkosuri]

Steps to Reproduce

1. Initialize step-ca with an ACME provisioner.
2. Edit ca.json to set termsOfService in the ACME provisioner, then restart step-ca.
3. Verify the ACME directory includes meta.termsOfService.
4. Create a new ACME account with termsOfServiceAgreed set to false or omitted.
5. Observe that the server still creates the account.

Your Environment

OS: Oracle Linux Server 8.10 (linux/amd64)
step-ca: Smallstep CA/0.28.4 (Release: 2025-07-14T14:06:51Z)
Kernel/Platform: platform:el8

Expected Behavior

When an ACME provisioner is configured with a termsOfService URL, the server should reject newAccount requests that do not set termsOfServiceAgreed: true, per RFC 8555 §7.3.3, returning an ACME problem with type userActionRequired and pointing to the terms URL.

Actual Behavior

• The server advertises meta.termsOfService in the directory.
• New ACME accounts are created even when termsOfServiceAgreed is false or omitted; no userActionRequired error is returned.

Additional Context

RFC: https://datatracker.ietf.org/doc/html/rfc8555#section-7.3.3

Code paths:

1. Directory meta includes termsOfService via provisioner: acme/api/handler.go (GetDirectory → createMetaObject)
2. Provisioner field: authority/provisioner/acme.go (TermsOfService string)
3. Missing enforcement in new-account: acme/api/account.go (NewAccount) — nar.Validate() only checks contacts; there is no check for prov.TermsOfService != "" && !nar.TermsOfServiceAgreed

Related prior work: PR #1136 added directory meta fields but did not add enforcement.

Proposed fix (brief): In acme/api/account.go::NewAccount, after nar.Validate() and loading the provisioner:

if prov.TermsOfService != "" and nar.TermsOfServiceAgreed != true, 
    return acme.ErrorUserActionRequiredType    # with a detail message including the terms URL.

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

[hslatman]

Hi @vkosuri, thank you for opening the issue. What is your use case for the functionality related to the terms of service? Given that step-ca is intended for private/internal PKI, adherance to the terms of service is generally not really a thing, since the CA is running internally, and "terms of service" are defined in other ways.

[vkosuri]

Thank you @hslatman. I apologise for the delay in my response. We have an ACME client implementation in place to verify our client implementation against the terms of service. We require this feature.

[hslatman]

Which ACME client?

[vkosuri]

Hi Herman, We are using our own custom client implementation rather than an open-source one. Best regards, Mallikarjunarao Kosuri

…

On Tue, 3 Feb 2026 at 15:11, Herman Slatman ***@***.***> wrote: *hslatman* left a comment (smallstep/certificates#2539) <#2539 (comment)> Which ACME client? — Reply to this email directly, view it on GitHub <#2539 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADIIAAMVTWY7RVJZL7GCHQD4KBULDAVCNFSM6AAAAACSAOEESGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQNBQGIYDGMRXG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[hslatman]

So it's not https://github.com/f5devcentral/kojot-acme?

If it's a custom implementation, it might be an option to add an option to ignore this case? I understand it may not be acceptable in every circumstance or use case, but it's currently the path of least resistance.

The reason I'm hesitant to just change the behavior on our side right now is that I'm not aware of issues with other ACME clients. They may, or may not, behave the same as your ACME client. Changing the behavior could be a breaking change for our users in terms of CA server behavior.

[vkosuri]

So it's not https://github.com/f5devcentral/kojot-acme?

No, we have implemented our own client within BigIP. BigIP will act as the ACME client.

The reason I'm hesitant to just change the behavior on our side right now is that I'm not aware of issues with other ACME clients. They may, or may not, behave the same as your ACME client. Changing the behavior could be a breaking change for our users in terms of CA server behavior.

I understand. Are there any plans for the future?