Boulder seems to invalidate older nonces after some time. Therefore we
allow nonces from the cache to be used for up to 2 minutes and after
those they will be considered invalid (and re-requested with an extra
request to the nonce endpoint when necessary)
start_challenge may raise an exception at any point. to not just destroy
the challenge but also try to stop it in order to clean up anything done
by start_challenge already properly
This simple implementation writes log messages to stdout/err and flushes
the buffers immediately after the message has been written.
Also update log messages with the certificate CN to a better readable format
Introduce functions for get_cert_cn and get_cert_valid_until to
encapsulate all cryptographic functions consistently in tools.
This is will isolate more cryptographic functions in the tools module
and allow for easier replacement of any cryptographic function should
the need ever arise
- Remove wait times returned by create_challenge
- Remove wait loops from authorities
- Add the wait for valid DNS TXT records in the abstract
DNSChallengeHandler start_challenge function.
- Move challenge verification to start_challenge in general
raw_result does not need an extra return, dicarding the nonce at that
point would discard the newer nonce from the response and also the first
nonce is gotten implicitly with the first request acme anyway
This changes the way the issuer CA is retrieved if no static_ca file is
used. Previously we would always download the CA using the AIA Info but
API v2 provides normally the full chain PEM upon certificate retrieval
and does not need this step. For the APIv2 case we now use the CA
provided with the certificate which required some changes to the basic
handling of CA files. APIv1 has been adapted to this new handling.
APIv2 has a fallback option to the way APIv1 handles it in case no CA
has been provided.
Authorities (e.g. Let's Encrypt) usually have Terms of Serivce (ToS)
that have to be agreed to. Up until this point we automatically
indicated agreement to those ToS and sent the necessary value.
This commit changes the behaviour to be in line with recommendations
from Let's Encrypt that the user themselves have to indicate their
agreement by no longer automatically doing so (except for cases of
legacy configuration files to provide compatibility).
The user can now indicate ToS agreement by either setting the associated
configuration variable (authority_tos_agreement) to the required value
and/or providing the required value via a command-line parameter
(--authority-tos-agreement=<value>/--tos-agreement=<value>/--tos=<value>)
Kishi85