RFC 8555 states that:
- when an account is successfully created, the server "returns this
account object" (section 7.3);
- the `orders` field in account objects is mandatory (section 7.1.2).
Despite that, Boulder does not returns the `orders` field when an
account is created. This non-standard behavior prevented ACMEd from
creating account and testing them for existence.
In order to allow ACMEd to retrieve certificates from CAs using Boulder,
the `orders` field is no longer mandatory and the account existence is
tested when the order is requested.
https://github.com/letsencrypt/boulder/issues/3335
The key hash is responsible for the initiation of a key rollover on
endpoints. Therefore, it should differ only when such an action is
required, which is only if the key pair has changed. For this, hashing
the public key is sufficient. Adding the signature algorithm will
generate unnecessary key rollovers.
In the Makefile, `make install` is used to create missing directories
and install files into them. Until now, the -D option was used for this
job. However, FreeBSD as an implementation of the install command that
differs about this option. In order to remain compatible with FreeBSD,
the -D option has been removed and replace by prior directory creation
using the -d option, which is common to (most?) implementations.
https://www.freebsd.org/cgi/man.cgi?query=installhttps://man.openbsd.org/installhttps://linux.die.net/man/1/install
The `dist: xenial` has been added because, at the time, build was done
using an old version of Ubuntu including an unsupported version of
OpenSSL. Now that Xenial is the default build version, this option
should be removed.
See commit 261e0e50fd
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