Sometimes, you want hooks to use different parameters depending on the
certificate. In order to achieve this, it is now now possible to
configure environment variables at certificate scope.
Thanks to this, the default hooks have been rewrote in order to use
cover more use cases.
Orders and authorization can both contain an error which can, for
example, help an user to fix a broken hook. It is therefore very useful
to display it.
Plus, when pooling one of those objects, having an error does not mean
we should stop pooling since the error may be temporary.
At some point, someone may add new domains to an existing certificate.
In such case, this certificate should be renewed as soon as possible
instead of upon expiration.
Documentation is a crucial point for every project, and the most
effective and traditional way to document a program is to write man
page. Here, the mdoc is used because it is simple.
Because the documentation is quite different from the project itself,
the man pages and others helpful files are distributed under a different
license. For this usage, the GNU All-Permissive License is adequate.
https://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html
man 7 groff_mdoc
The previous system was too limited when it comes to flexibility using
hooks. This limitation came from the false idea that, for a given
certificate, all challenges must be validated with the same method. In
order to prove that false, domains in a certificate can now make use of
any challenge type available.
In order to be more flexible, hooks are now given a type and are defined
in the same registry (instead of 6). Each one will be called when
considered relevant based on its type.
Some errors, like the badNonce one, are recoverable. Hence, the client
is expected to retry. ACMEd will now re-send the associated request
until it succeed or the max retries number is reached. Each retry is
preceded by a small waiting time in order to let the server recover in
case it was faulty.
Defining an account solely by an email address is not the best strategy
since the ACME protocol does not require it and also allows for more
contacts information. Although this commit does not change the "one
email" policy, it sets the bases so it could evolve in the future.
Although the `acme-lib` crate comes very handy when creating a simple
ACME client, a more advanced one may not want to use it. First of all,
`acme-lib` does not support all of the ACME specification, some very
interesting one are not implemented. Also, it does not store the account
public key, which does not allow to revoke certificates.
In addition to those two critical points, I would also add `acme-lib`
has some troubles with its own dependencies: it uses both `openssl` and
`ring`, which is redundant and contribute to inflate the size of the
binary. Some of the dependencies also makes an excessive use of logging:
even if logging is very useful, in some cases it really is too much and
debugging becomes a nightmare.
ref #1
It is considered a good practice to archive old certificates and private
keys instead of simply dropping them away. Because ACMEd should not
impose a way of doing things to system administrators, hooks are the way
to go.
Some configurations may require to run the same bunch of hooks for
several domains. In order to limit repetition, it is now possible to
create a group that will reference to hooks or hook groups.
The default behavior of most ACME clients is to generate a new key pair
at each renewal. While this choice is respectable and perfectly
justified in most configuration, it is also quite incompatible with the
use of HTTP Public Key Pinning (HPKP). Although HPKP is not wildly
supported and sometimes deprecated, users wishing to use it should not
be blocked.
https://tools.ietf.org/html/rfc7469https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning
Rodolphe Breard