Commit graph

6 commits

Author SHA1 Message Date
David Cowden
a26b5f322d acme/api: Brush up documentation on key-change
Add more specific wording describing what a 501 means and add more color
explaining how official vs unofficial error types should be handled.
2020-05-28 11:22:37 -07:00
David Cowden
b26e6e42b3 acme: Return 501 for the key-change route
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
2020-05-26 01:47:08 -07:00
max furman
e1409349f3 Allow relative URL for all links in ACME api ...
* Pass the request context all the way down the ACME stack.
* Save baseURL in context and use when generating ACME urls.
2020-05-14 17:32:54 -07:00
Clive Jevons
639993bd09 Read host and protocol information from request for links
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).
2020-05-12 16:58:12 -07:00
max furman
d368791606 Add x5c provisioner capabilities 2019-10-14 14:51:37 -07:00
max furman
e3826dd1c3 Add ACME CA capabilities 2019-09-13 15:48:33 -07:00