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.
* api/render: initial implementation of the package
* acme/api: refactored to support api/render
* authority/admin: refactored to support api/render
* ca: refactored to support api/render
* api: refactored to support api/render
* api/render: implemented Error
* api: refactored to support api/render.Error
* acme/api: refactored to support api/render.Error
* authority/admin: refactored to support api/render.Error
* ca: refactored to support api/render.Error
* ca: fixed broken tests
* api/render, api/log: moved error logging to this package
* acme: refactored Error so that it implements render.RenderableError
* authority/admin: refactored Error so that it implements render.RenderableError
* api/render: implemented RenderableError
* api/render: added test coverage for Error
* api/render: implemented statusCodeFromError
* api: refactored RootsPEM to work with render.Error
* acme, authority/admin: fixed pointer receiver name for consistency
* api/render, errs: moved StatusCoder & StackTracer to the render package
RFC 8555 § 7.3.5 is not listed as optional but we do not currently
support it. Rather than 404, return a 501 to inform clients that this
functionality is not yet implemented.
The notImplmented error type is not an official error registered in the
ietf:params:acme:error namespace, so prefix if with step:acme:error. An
ACME server is allowed to return other errors and clients should display
the message detail to users.
Fixes: https://github.com/smallstep/certificates/issues/209
When constructing links we want to read the required host and protocol
information in a dynamic manner from the request for constructing ACME
links such as the directory information. This way, if the server is
running behind a proxy, and we don't know what the exposed URL should
be at runtime, we can construct the required information from the
host, tls and X-Forwarded-Proto fields in the HTTP request.
Inspired by the LetsEncrypt Boulder project (web/relative.go).
