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
Due to a bug in the `acme-lib` dependency, the Certificate Signing
Request was not built correctly. This issue caused the ACME server to
reject such CSR when ordiring more than two domains.
algesten/acme-lib#3
Not doing so may result in race conditions, hence breaking the promise
that hooks are called in sequential order.
Also, debug output has been added to the hooks.
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.
When hooks are called, there is an option to feed stdin with a custom
string. However, if any error happen, the .unwrap() causes the daemon
to panic. This fix transforms it into an error than can be handled.
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
Both markdown and CommonMark support only 2 level of heading underline.
A third level using the `~` character is only supported as an extension
in some implementations. While GitHub and most software do not support
it, it is a better choice to switch to ATX headings.
https://daringfireball.net/projects/markdown/syntaxhttps://spec.commonmark.org/