Certbot - Wrong Paramaters Result in New Certificates Not Being Issued

[JamieMcNaught]

Hi all,

TLDR - Is there a simple way to create a new cert if it doesn’t already exist for the domain or if it does exist, only renew it if it’s about to expire?

Background - I’ve got a number of dev servers running continuous testing. They start almost blank (they had an initialisation script run to setup standard software (e.g. git), including LetsEncrypt, but without the certs), we then run a deployment script for our software (where we’d like to setup the LetsEncrypt certs) and then tests.

Problem is, we’re hitting the limits on certificate generation.

The deployment script runs in Python (fabric) - non-root. It only calls sudo when needed so we can’t easily access the certs to check their creation dates in python, so was hoping Lets Encrypt could do the “create or update” in a single sudo call.

Hope you can help,

Jamie

My domain is:
hcp1.ddns.net

I ran this command:
/opt/letsencrypt/letsencrypt-auto certonly --non-interactive --agree-tos --email me@mydomain.com --domain hcp1.ddns.net --renew-by-default --webroot -w /var/hcp1/www

It produced this output:
[jamie@localhost] out: Saving debug log to /var/log/letsencrypt/letsencrypt.log
[jamie@localhost] out: Renewing an existing certificate
[jamie@localhost] out: Performing the following challenges:
[jamie@localhost] out: http-01 challenge for hcp1.ddns.net
[jamie@localhost] out: Using the webroot path /var/hcp1/www for all unmatched domains.
[jamie@localhost] out: Waiting for verification…
[jamie@localhost] out: Cleaning up challenges
[jamie@localhost] out: An unexpected error occurred:
[jamie@localhost] out: There were too many requests of a given type :: Error creating new cert :: too many certificates already issued for exact set of domains: hcp1.ddns.net
[jamie@localhost] out: Please see the logfiles in /var/log/letsencrypt for more details.

My operating system is (include version):
Ubuntu 14.04

My web server is (include version):
nginx version: nginx/1.10.3

[schoen]

Hi @JamieMcNaught,

This sounds like a good application for shell scripting. You could create a shell script which you run with sudo which checks for the existence of a particular cert.

To test for the existence of a cert by name, you can use something like

[ -d /etc/letsencrypt/live/example.com ]

To find the expiry time of a cert (here with +%s to convert it to Unix time in seconds since 1970)

date -d "$(openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem -enddate -noout | cut -d= -f2)" +%s

If you do a completely fresh deploy very frequently, you might not be able to avoid the rate limits unless you back up an existing certificate somewhere and then retrieve it from the backup.

[jmorahan]

I think what you want is to use --keep-until-expiring instead of --renew-by-default.

[schoen]

Actually I just remembered that there is also certbot certonly --keep, which will already do something similar to what you want.

Edit: @jmorahan beat me to this useful suggestion by a few seconds!

[jmorahan]

Cool, I didn’t know about the shorter version

[schoen]

All Certbot long options can be abbreviated to the shortest unique form.

This is usually true in software that uses GNU-style long options. For example, the long form of ls -R is ls --recursive, but the program will accept ls --recursiv, ls --recursi, etc., on down to ls --rec (but not ls --re, which is ambiguous with --reverse).

The most common case for Certbot users --force-renew, which is technically actually an abbreviation of --force-renewal! You could even abbreviate it further if you wanted to.

[JamieMcNaught]

@schoen

--keep,

Fantastic @jmorahan and @schoen - that's exactly what I was looking for and I can now dispose of a collection of shell scripts which were trying to do the same thing and getting hit by permission issues.