When the RA mode with StepCAS is used, let the CA decide which lifetime
the RA should get instead of requiring always 24h.
This commit also fixes linter warnings.
Related to #1094
Apparently the Apple macOS (and iOS?) ACME client seems to omit
leading null bytes from JWS signatures. The base64-url encoded
bytes decode to a shorter byte slice than what the JOSE library
expects (e.g. 63 bytes instead of 64 bytes for ES256), and then
results in a `jose.ErrCryptoFailure`.
This commit retries verification of the JWS in case the first
verification fails with `jose.ErrCryptoFailure`. The signatures are
checked to be of the correct length, and if not, null bytes are
prepended to the signature. Then verification is retried, which
might fail again, but for other reasons. On success, the payload
is returned.
Apple should fix this in their ACME client, but in the meantime
this commit prevents some "bad request" error cases from happening.
Upgrade chi to the v5 module path to avoid deprecation warning about v4
and earlier on the old module path.
See https://github.com/go-chi/chi/blob/v4.1.3/go.mod#L1-L4
Signed-off-by: Dominic Evans <dominic.evans@uk.ibm.com>
* 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)
Harware appliances from Kemp seem to validate the contents of the
`meta` object, even if none of the properties in the `meta` object
is set. According to the RFC, the `meta` object, as well as its
properties are optional, so technically this should be fixed by
the manufacturer.
This commit is to see if we validation of the `meta` object is
skipped if it's not available in the response.
Mariano Cano
Herman Slatman
Dominic Evans
Max
Brandon Weeks
Shulhan
Herman Slatman