This is a breaking change!
Changes the id for configurations with a key algorithm set, which by default results in changes to serveral dependent configuration values as well,
such as cert_file/key_file/csr_file. This will require existing ECC setups to append the ecc suffix to files in the acertmgr configuration directory
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.
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.
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
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>)
This adds a few basic command line parameters to allow further
customization of the configuration locations. As well as defining new
default locations for the acertmgr config files and updating the parser
with missing values, so that the config dictionary provided to the
acertmgr process after parsing is complete and no cross reference to the
configuration module is necessary. The parser error handling is also
improved.
Rudolf Mayerhofer
Markus