Remove the long-standing todo from cert_put and implement useful
error handling and defaults for certificate deployment. Also do
a separate try/expect for each deployed file on every single
certificate.
If no configuration matching the domains in the given certificate exist
use the globalconfig/default settings for an authority to revoke the
certificate (which might still fail if things do not match up, but the
authority will decide on that)
Configuration parsing for the authority settings is therefore split into
a seperate function which will be called for the 'fallback_authority'
element in runtimeconfig.
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
This may also be used to guarantee a correct TXT record lookup by setting
dns_verify_all_ns=true, a dns_verify_failtime < dns_verify_waittime and
a high enough value of dns_verify_failtime (like 300 seconds)
- 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
If anything goes wrong during cert_get/cert_put/running
actions/cert_revoke superseded do not fail completely and continue with
the remaining domains to process. Print all exceptions and after
processing raise a RuntimeError
as certificate renewal might take some time (on DNS-01 especially) it is
a good idea to wait with deployment until all certificates are finished
renewing and copy them to their destinations then + run actions
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
Store the generated CSR for later review/usage and allow the stored
CSR to be used for future request. Configuration directives csr_file
(path) and csr_static (=true) have been added for this.
This allows simplified deployment of DANE/TLSA due the former requiring
updates to DNS with every public key change, which will not be the case
with a static CSR. A new CSR can be triggered manually by deleting the
CSR file upon which the next certificate will require an update of any
TLSA records in DNS.
This may also be used to specify a custom CSR to use, as long as the
csr_file path and the domains in the CSR match the ones given in the
acertmgr configuration.
- Print warnings when certain configuration options are used
- Print warnings when old file/directory paths are used
- Fix compatibility with old configurations expecting v1 API for now
Do not fail if there is no issuer CA download possible in any way. Just
let the user provide the (static) CA certifiate at ca_file or fail during
certificate deployment.
