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)
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.
At some point, someone may add new domains to an existing certificate.
In such case, this certificate should be renewed as soon as possible
instead of upon expiration.
The previous system was too limited when it comes to flexibility using
hooks. This limitation came from the false idea that, for a given
certificate, all challenges must be validated with the same method. In
order to prove that false, domains in a certificate can now make use of
any challenge type available.
In order to be more flexible, hooks are now given a type and are defined
in the same registry (instead of 6). Each one will be called when
considered relevant based on its type.
As stated in the RFC 8555, the client should explicitly ask the user for
the terms of service agreement. In the case of ACMEd, the retained
method is to ask for a `tos_agreed` field to be set to true or false in
the configuration. This field has been set in the endpoint object rather
than in the account one because the same account can be used on multiple
endpoints.
Defining an account solely by an email address is not the best strategy
since the ACME protocol does not require it and also allows for more
contacts information. Although this commit does not change the "one
email" policy, it sets the bases so it could evolve in the future.
Although the `acme-lib` crate comes very handy when creating a simple
ACME client, a more advanced one may not want to use it. First of all,
`acme-lib` does not support all of the ACME specification, some very
interesting one are not implemented. Also, it does not store the account
public key, which does not allow to revoke certificates.
In addition to those two critical points, I would also add `acme-lib`
has some troubles with its own dependencies: it uses both `openssl` and
`ring`, which is redundant and contribute to inflate the size of the
binary. Some of the dependencies also makes an excessive use of logging:
even if logging is very useful, in some cases it really is too much and
debugging becomes a nightmare.
ref #1
Rodolphe Breard
Danilo Bargen
Jakub Pastuszek