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.
`reqwest` is a very good crate, however ACMEd does not require most of
its functionalities. For this job, `attohttpc` is also great and comes
with much less dependencies.
rel #1
The previous HTTP back-end was tightly coupled with the threads, which
was very inconvenient. It is now completely decoupled so a new threading
model may be implemented.
The PID file is now always written whether or not ACMEd is running in
the foreground. Previously, it was written only when running in the
background.
Fix#7
This project provides binaries without any link to Rust or Cargo. It is
just normal binaries that appears to be written in Rust. Therefore, it
does not makes any sense to distribute them in a Rust-specific registry.
Furthermore, such publication would not include the man pages
installation may not respect some distribution-specific policies.
As discussed in #2, ring is not mature enough to replace OpenSSL. Hence,
the standalone mode which has been made to implement such a replacement
has to be removed until ring becomes usable.