| Age | Commit message (Collapse) | Author |
|---|
|
lego will by default use the current directory to look for accounts/keys. That
makes sense if you want to keep deployments separated, but in my case, I have a
single deployment and want to be able to run the command from anywhere.
|
|
Historically, this script only allowed renewal. This would break whenever
subdomains were added to or removed from the config file, since, when renewing
a certificate, the subdomains must remain the same as last time.
I got around this by manually modifying the script each time I had to create a
new cert. That's risky though, so introduce the structure to allow this to be
passed from the terminal.
|
|
I would like different domains to have different renew-days, so that the certs
for different domains do not always update on the same day as each other. This
prevents a worst-case scenario where all domains break on one day.
|
|
If we are renewing via DNS-01, we need to make sure to reuse the same key -
otherwise, we will need a different hash to be propagated via DNS, which
reuqires multiple days for a proper rollover. DANE will break if this rollover
is not done.
|
|
I will be adding more flags to this list, and it will get too long for one
line.
|
|
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.
|
