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
Each endpoint can safely renew its certificates at the same time as
other endpoints. Hence, this operation is now done within a new thread
for each endpoint.
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.
Having the data relative to the endpoint in the certificate structure
makes no sense. There is no way to share it across certificates which is
sometimes needed. Also, having the other part of the endpoint data
(mostly nonce and rate limit) in different places makes it difficult to
maintain.
Hence, the endpoint structure has been created. For now it is quite
simple and does not handle every aspects of the endpoint, but this will
be implemented in the future.
Right now only the id is logged as a prefix (e.g. crt-3), so it's not
possible to easily determine *which* certificate was renewed, or failed
to renew.
The threading architecture was not good at all. It was built around the HTTP part, which isn't flexible enough. Hence, the decision has been made to refactor both of those parts. This will takes 4 steps :
1. remove threads and rate limits (this commit)
2. refactor the HTTP part (the tricky part)
3. reintroduce rate-limits (quite easy)
4. introduce a new threading system (the easiest part)
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
In some situations, it has been found that a specific ACME server
returns extra characters before and after the JSON, which is therefore
invalid. Although this must be fixed in the server, ACMEd should
gracefully ignore such erroneous characters instead of refusing the
response.
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.
If several certificates uses the same account and this account doesn't
exists yet, they will both try to create it, resulting in a race
condition. This commit solves the problem by creating the account key
pair at startup. Account creation on the endpoint is not subject to a
race condition since the request does not differ from the one used to
retrieve the account id.
Fix#3
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.