| Age | Commit message (Collapse) | Author |
|---|
|
This is used to determine the letsencrypt endpoint to hit.
I used to have a single variable for the endpoint, and I would uncomment the
prod or nonprod endpoint depending on the circumstances.
The two endpoints are given in separate variables in the config file:
acme_server_nonprod and acme_server_prod. Likewise, the renew_script variable
has been split into renew_script_nonprod and renew_script_prod. Choose between
them using the argument.
|
|
We now have different domains managed by different DNS providers. Select the
provider per-domain based on the config file.
|
|
mercuric.uk is now using Mythic Beasts instead of deSEC for DNS, and I'll be
moving the other domains shortly. As a result, I would like to be able to
select between providers them in the config file.
As a first step towards supporting Mythic Beasts, pass the API key ID and
secret to lego.
We can do this in all circumstances: it will be unused if we don't specify
mythicbeasts when the command is invoked.
|
|
I use letsencrypt's nonprod server when testing renewals - especially when
setting up new domains.
I used to have two lines in the config file - one for prod and one for nonprod,
only one of which would be uncommented at any given time.
However, especially since I started running the script via a cron job, there
was a risk that I would forget to change it back.
The end goal is to control the environment via a flag to the renew-all script.
As a first step towards this, hardcode the environment as prod here.
|
|
When I still had a domain for motoristic, I had separate emails and tokens for
it, the idea being that I could hand it over to someone else more easily.
However, I deleted the motoristic server some time ago, and since then, all
servers have used the same email and token. Therefore, retrieve this info from
the common config section instead of the domain-specific section.
|
|
The config file gets installed to here in reality. I could introduce some
config, for example overwriting this during the build process, I think that
would be overkill.
|
|
Different domains are managed by different identities both in deSEC and
letsencrypt. Therefore, we should store these per domain, instead of globally.
|
|
This commit adds the initial structure / scaffolding on which the rest of the
project can be built.
The idea is to have an entry point written in python, which parses a toml file
which contains information about each domain, and general configuration of the
lego tool which will actually renew the certificates. Each domain has an
additional post-renew script, the path to which is given in the config file,
which is used to install the new certificates onto the remote hosts if
necessary.
|
