The previous strategy for accounts management on endpoints was to send
an account creation request every time in order to retrieve the account
URL. Although it works on most cases, the contact information or key
update wasn't handled correctly.
The only drawback of this new way of managing accounts is that, if the
endpoints drops the account, ACMEd will fail to renew any certificate
for this account on this endpoint. Previously, it would have simply
created a new account. This should be fixed soon.
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 certificate struct was bloated with file management data which
therefore required the certificate to be passed in every storage
function. In order to clean this, a new FileManager struct has been
created.
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`.
Currently, OpenSSL does not have the required
`EVP_PKEY_get1_ED(25519|448)` functions, hence EdDSA has been partially
implemented and disabled. Once OpenSSL 3.0.0 is out and the `openssl`
crates implements the bindings to those functions, full EdDSA
implementation could be done and activated.
Conditional compilation has been implemented using `rustc-cfg`
instructions rather than features so it can be activated from the build
script depending on whether or not the cryptographic library supports
Ed25519 and Ed448.
7c664b1f1b
Being tied with the key type, the signature algorithm should therefore
be at the same place than the key type, hence `acme_common::crypto`.
This reorganization will allow to specify the account key type as well
as the signature algorithm in the configuration.
Since there is currently no possibility to chose a different account key
type, the current implementation only supports the ES256 algorithm. With
the upcoming support of different key types, it had to be changed. This
commit add support for ES384 although there is no configuration option
that can activate the actual use of it through account keys using the
NIST P-384 curve.
The previous version of the Makefile used features which are specific to
GNU Make and therefore does not works on BSD systems. This new version,
which is much more simpler, works both on GNU Make and BSD Make (tested
on FreeBSD 12.1).