step-ca EAB auto-issuance failure and unclear EAB validation behavior

[kimhanbeom]

What I observed

1. EAB auto-issuance fails during bootroot init and bootroot rotate eab

   Register EAB now? [y/N]: y
   Auto-issue EAB via step-ca? [y/N]: y
   bootroot init failed
   details: Automatic EAB issuance failed

   OpenBao root token: [token value]
   Rotate ACME EAB credentials? [y/N]: y
   bootroot rotate failed
   details: Automatic EAB issuance failed

2. ACME endpoint behavior in step-ca

   POST /acme/acme/eab → 404
   GET /acme/acme/directory → Successful response

   → It seems that the EAB endpoint itself is not available.

3. Attempt to create EAB key via step-ca CLI

   step ca acme eab add acme ...

   Result:

   error creating ACME EAB key:
   this functionality is currently only available in Certificate Manager

   → It appears that EAB key creation is not supported in the OSS version.

4. Runtime behavior verification
   Set arbitrary EAB values in agent.toml and ran bootroot-agent

   [eab]
   kid = "dev-kip"
   hmac = "dev-hmap"
   
   [profiles.eab]
   kid = "dev-kip"
   hmac = "dev-hmap"

   → cert and keys were still issued successfully, which suggests that EAB values are not being validated in this flow.

5. Findings from documentation
   From the official documentation and blog posts, it seems that EAB is not supported in step-ca OSS:

   • https://smallstep.com/docs/step-ca/acme-basics/#why-acme
     → "This feature is available in Smallstep's commercial CA software."
   • https://smallstep.com/docs/step-ca/#limitations
     → "No support for ACME External Account Binding (EAB)"
   • https://smallstep.com/blog/acme-eab-overview/
     → "Our open source step ca certificate authority offering does not support EAB. EAB is for more advanced ACME use cases, and is only supported in our commercial offering"

Question

Based on the behavior above and Smallstep’s documentation, is it correct that bootroot currently cannot auto-issue ACME EAB credentials with step-ca OSS?
If this understanding is correct, it seems that one of the following approaches could be taken:
(1) disable or fail-fast the EAB auto-issuance path for this backend
(2) keep it but clearly document that EAB requires Smallstep Certificate Manager.