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:
I ran this command:
certbot certonly --agree-tos --webroot --webroot-path=/var/www/public/letsencrypt --email firstname.lastname@example.org --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:
I can login to a root shell on my machine (yes or no, or I don’t know):
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.