* Store and verify account location on acme requests
Co-authored-by: Herman Slatman <hslatman@users.noreply.github.com>
Co-authored-by: Mariano Cano <mariano@smallstep.com>
When validating an ACME challenge (`device-attest-01` in this case,
but it's also true for others), and validation fails, the CA didn't
return a lot of information about why the challenge had failed. By
introducing the ACME `Subproblem` type, an ACME `Error` can include
some additional information about what went wrong when validating
the challenge.
This is a WIP commit. The `Subproblem` isn't created in many code
paths yet, just for the `step` format at the moment. Will probably
follow up with some more improvements to how the ACME error is
handled. Also need to cleanup some debug things (q.Q)
Although this may slow certain API calls down and may not be, strictly
necessary, I think it's best to put all the ACME EAB operations behind
RW locks to prevent concurrent updates to the DB and guarantee
consistent result sets.
Before this commit, EAB keys could be used CA-wide, meaning that
an EAB credential could be used at any ACME provisioner. This
commit changes that behavior, so that EAB credentials are now
intended to be used with a specific ACME provisioner. I think
that makes sense, because from the perspective of an ACME client
the provisioner is like a distinct CA.
Besides that this commit also includes the first tests for EAB.
The logic for creating the EAB JWS as a client has been taken
from github.com/mholt/acmez. This logic may be moved or otherwise
sourced (i.e. from a vendor) as soon as the step client also
(needs to) support(s) EAB with ACME.
Mariano Cano
Max
Herman Slatman