* 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)
This change adds the flags --acme-http-port, --acme-tls-port, that
combined with --insecure can be used to set custom ports for ACME
http-01 and tls-alpn-01 challenges. These flags should only be used
for testing purposes.
Fixes#1015
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.
There are YubiKeys v5.2.4 where the attestation intermediate (f9)
does not have a basic constraint extension, so that certificate
is not marked as a CA. The test and CA in this commit imitates
that use case. Currently the test case returns an error as we
don't support it. But if we change the verification to support
this use case, the test should change accordingly.
Herman Slatman
Max
Mariano Cano
Mariano Cano
Andrew Reed