- Each acme account has an index in this table. Before this change, the
index would grow unchecked as orders accumulate. This change removes
orders that have moved out of the 'PENDING' state.
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
Modify existing tests to pass with changes introduced in commit
322200b7db. This is safe to do as
tests assert exact length of modifiers, which has changed.
When `forceCN` is set in provisioner configuration and
Subject.CommonName is empty, set Subject.CommonName to the first SAN
from the CSR to follow the letsencrypt's boulder behavior. This is done
in order to support system which require certificate's Subject field to
be non-empty.
N.B. certbot does not send Subject in its certificate request and relies
on similar behavior of letsencrypt.
Closes https://github.com/smallstep/certificates/issues/259
Add configuration option `forceCN` to ACME provisioner. When this option
is set to `true`, provisioner should generate Subject.CommonName for
certificate if it was not present in the request. Default value of
`false` should keep the existing behavior (do not modify CSR and
certificate).
Ref: https://github.com/smallstep/certificates/issues/259
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).
Miclain K Keffeler
Max
David Cowden
Mariano Cano
Oleksandr Kovalchuk
Clive Jevons