Have I got the wrong assumptions about the lifecycle of certificates

[timcoote]

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:
gitlab.iotaa.co.uk
I ran this command:
certbot certonly --agree-tos --webroot --webroot-path=/var/www/public/letsencrypt --email tim.coote@differentis.com --preferred-challenges http -d gitlab.iotaa.co.uk -n
It produced this output:
There were too many requests of a given type :: Error creating new cert :: too many certificates already issued for exact set of domains: gitlab.iotaa.co.uk
My web server is (include version):
nginx version: nginx/1.10.3 (Ubuntu)
The operating system my web server runs on is (include version):
DISTRIB_DESCRIPTION="Ubuntu 16.04.3 LTS"
My hosting provider, if applicable, is:
AWS
I can login to a root shell on my machine (yes or no, or I don’t know):
Maybe
I’m using a control panel to manage my site (no, or provide the name and version of the control panel): No.

I think that I may be approaching this situation with some mis-matched assumptions. I’m automating the building of my build pipeline, with a plan to redeploy regularly. I’m approaching the certificate issuance as an event that happens each time that I spin up the environment. I’ve done most of the testing with the --staging flag to avoid throttling, but this breaks the certificate chain validation (as expected).

Am I correct in thinking that the letsencrypt operational model assumes that certificates are issued and remain in-situ for an extended period, and then renewed? Rather than my approach which is to destroy old sets of certificates and start again, so that I don’t have to worry about managing a secure storage location, and I reduce the risk of finding that we’ve got a snowflake server.

Otherwise, thanks for the effort in putting this service together. It’s excellent.

tia

Tim

[tialaramex]

Yes, you should persist the certificate. Let’s Encrypt is a rate limited service. Also, if you don’t persist the certificate then you introduce a dependency where if Let’s Encrypt is temporarily unavailable your service can’t be started - that’s clearly the Wrong Thing.

Aim to replace certificates a few weeks before they expire but not much earlier. This gives you enough time to be alerted if renewal fails, discuss it and take action in an unhurried way, without much increasing the work for Let’s Encrypt

[timcoote]

Thanks.

I’m not sure that there is a definitive Wrong Thing. All things are trade-offs. In this case removing the occasional service dependency is traded off against a more complex implementation and the externalisation of credentials, both of which introduce new risks.

It is what it is. I can work with it.