Being able to define root certificates in the command line is not enough
for two reasons:
1. It is always global, you cannot define a root certificate for a
specific endpoint.
2. Daemon scripts and unit files are not meant to be changed every time
you need to add a root certificate.
For those reasons, it is now to possible to define root certificates in
the configuration. Those defined in the `global` section will be used on
every endpoint, just like those added via the command line. Those
defined in an endpoint will be used in this endpoint only.
Until now, the account management was archaic and it was impossible to
improve it without this heavy refactoring. Accounts are now disjoint
from both certificates and endpoints. They have their own hooks and
their own environment variables. They are stored in a binary file
instead of the PEM exports of the private and public keys.
This refactoring will allow account management to evolve into something
more serious, with real key rollover, contact information update and so
on.
The previous system used a duplicated enum
(`acmed::certificate::Algorithm`) and an imprecise identifier name
(algorithm) for both the certificate configuration and post operation
hook variable. The first one has been replaced by the
`acme_common::crypto::KeyType` enum and the second renames `key_type`.
There is use-cases where a command's standard input should be filled
with a file's content. In order to stay consistent with the names of the
other fields, `stdin` is now the field which accepts such a path.
`stdin_str` has been created in order to also support the use of a raw
string.
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.
If someone used the example the way it was defined, file-access issues
may arise. This new example add two new hooks to fix it. The example
should now work in most environment although the path may need to be
adapted.
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