Because ring does not currently support RSA keys generation, the default
algo must be adapted depending on whether or not the standalone feature
is activated.
Since it is planned to add a "standalone" feature that will replace
OpenSSL by crates not linking to any external library, it is required to
abstract all the OpenSSL specific types. This is a huge work and
therefore is divided in several steps. This first one is dedicated to
public and private keys.
rel #2
Sometimes, grep is used to find the TODO comments. Without the proper
explanation, it is hard to know what it refers to (-C / --context may
produce a too large output).
There is use-cases where a command's standard input should be filled
with a file's content. In order to stay consistent with the names of the
other fields, `stdin` is now the field which accepts such a path.
`stdin_str` has been created in order to also support the use of a raw
string.
Cleaning hooks after the certificate has been retrieved is a mistake
since a failure somewhere in the process will prevent all called hook to
be cleaned. With the current implementation, only the currently failed
hook is left without being cleaned.
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.
Orders and authorization can both contain an error which can, for
example, help an user to fix a broken hook. It is therefore very useful
to display it.
Plus, when pooling one of those objects, having an error does not mean
we should stop pooling since the error may be temporary.
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.
If a configuration field has a typo in its name, the configuration
should show an error message instead of silently ignoring this field,
which could create unwanted behavior.
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.
Sometimes, it is not possible to use certificates signed by a known
certificate authority. Hence, in order to prevent a TLS error, it is
required to explicitly add a new trusted root certificate.
This is the case with Pebble, which provides the certificate.
https://github.com/letsencrypt/pebble#avoiding-client-https-errors
The account public and private keys are stored in files with names
derives from the account name itself. Because the account name may
contain characters incompatible with a file name, it needs to be
sanitized. Additionally, the account files does not need to be publicly
accessed, therefore their name should only be deterministic. This last
property allows to use a simple solution for sanitation: encode the name
in base64. This way, it is deterministic, unique for each account and
only contains safe characters.
Note the base64 variant used is, as for the ACME protocol, the one with
the URL and filename safe alphabet
https://tools.ietf.org/html/rfc4648#section-5
Some errors, like the badNonce one, are recoverable. Hence, the client
is expected to retry. ACMEd will now re-send the associated request
until it succeed or the max retries number is reached. Each retry is
preceded by a small waiting time in order to let the server recover in
case it was faulty.