Running Renewal Script doesn't renew cert


Hi all, Happy New Year :slight_smile:

Just been renewing a certificate that expired in December but having a few issues, the autorenewal scripts are completing and showing the “Congratulations!” message, but the certificate expiry is the same, 2016-12-03…

The domain is

Commands run are:
letsencrypt-auto renew
letsencrypt-auto certonly --standalone -d -d -d -d -d

Both of which are completing but not renewing the cert.

Output from renew command:
Processing /etc/letsencrypt/renewal/

Cert is due for renewal, auto-renewing…
Starting new HTTPS connection (1):
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for
tls-sni-01 challenge for
tls-sni-01 challenge for
tls-sni-01 challenge for
tls-sni-01 challenge for
Waiting for verification…
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0036_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0036_csr-certbot.pem

Output from certonly command:

  • Congratulations! Your certificate and chain have been saved at
    /etc/letsencrypt/live/ Your cert will
    expire on 2016-12-03. To obtain a new or tweaked version of this
    certificate in the future, simply run letsencrypt-auto again. To
    non-interactively renew all of your certificates, run
    "letsencrypt-auto renew"

My operating system is Debian 8.6

My web server is Nginx/1.6.2

I can root into the machine, and all commands have been run as root.

and of course, after trying a couple of times, I’m now being rate limited:

Attempting to renew cert from /etc/letsencrypt/renewal/ produced an unexpected error: urn:acme:error:rateLimited :: There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for exact set of domains:,,,, Skipping.


Could you run ls -l /etc/letsencrypt/live/ and ls -l /etc/letsencrypt/archive/ and paste the output of both commands here?

It sounds like the symlinks in the /live directory have been replaced by actual files or something like that. In all likelihood, the renewed certificates and the corresponding keys are available somewhere in /archive.


Hi @pfg , thanks for getting back so quickly.

Results are below:
{17-01-03 13:06}vps1:/usr/src/letsencrypt@master✗✗✗✗✗✗ root# ls -l /etc/letsencrypt/live/
total 0
lrwxrwxrwx 1 root root 41 Jan 3 12:04 cert.pem -> …/…/archive/
lrwxrwxrwx 1 root root 42 Jan 3 12:04 chain.pem -> …/…/archive/
lrwxrwxrwx 1 root root 46 Jan 3 12:04 fullchain.pem -> …/…/archive/
lrwxrwxrwx 1 root root 44 Jan 3 12:04 privkey.pem -> …/…/archive/
{17-01-03 13:11}vps1:/usr/src/letsencrypt@master✗✗✗✗✗✗ root# ls -l /etc/letsencrypt/archive/
total 64
-rw-r–r-- 1 root root 1866 Jun 14 2016 cert1.pem
-rw-r–r-- 1 root root 1899 Jan 3 12:04 cert2.pem
-rw-r–r-- 1 root root 1891 Sep 1 15:14 cert3.pem
-rw-r–r-- 1 root root 1915 Sep 3 21:15 cert4.pem
-rw-r–r-- 1 root root 1647 Jun 14 2016 chain1.pem
-rw-r–r-- 1 root root 1647 Jan 3 12:04 chain2.pem
-rw-r–r-- 1 root root 1647 Sep 1 15:14 chain3.pem
-rw-r–r-- 1 root root 1647 Sep 3 21:15 chain4.pem
-rw-r–r-- 1 root root 3513 Jun 14 2016 fullchain1.pem
-rw-r–r-- 1 root root 3546 Jan 3 12:04 fullchain2.pem
-rw-r–r-- 1 root root 3538 Sep 1 15:14 fullchain3.pem
-rw-r–r-- 1 root root 3562 Sep 3 21:15 fullchain4.pem
-rw-r–r-- 1 root root 1704 Jun 14 2016 privkey1.pem
-rw-r–r-- 1 root root 1704 Jan 3 12:04 privkey2.pem
-rw-r–r-- 1 root root 1708 Sep 1 15:14 privkey3.pem
-rw-r–r-- 1 root root 1708 Sep 3 21:15 privkey4.pem
{17-01-03 13:12}vps1:/usr/src/letsencrypt@master✗✗✗✗✗✗ root#

As you say, looks like there are some issues with regards the symlinks. Unfortunately, symlinking not a strongpoint in my nix knowledge. The *2.pem’s look like the new ones, is there any way of me resolving this so that future renewals won’t require manual intervention? (i.e. clean everything up, repoint)


It looks like you might have a second certificate lineage (, and for some reason the symlinks point to that directory rather than the one without -0001. That’s not something the client should do; perhaps this was the result of an attempt to merge the new lineage (which might have been created when you tried to add a subdomain without providing the --expand flag) with the old one manually?

Usually, I would recommend backing up and deleting /etc/letsencrypt entirely to start from scratch and just request the certificates again, but since you’re being rate-limited right now, that’s not really an option right now. You could update all the symlinks in /live to the corresponding most recent file in /archive via:

ln -s -f /etc/letsencrypt/archive/<file><biggest_number>.pem /etc/letsencrypt/live/<file>.pem

You’ll probably want to disable any renewal cronjobs for now and still delete /etc/letsencrypt and re-issue all certificates in a week once the rate-limiting period has expired; trying to manually fix these issues while getting renewal to work tends to be rather error-prone.


That’s probably not a very good idea, the biggest number being a certificate generated in September :wink:

Looks like the numbering is broken too, the cert from January being number 2.

letsencrypt renew

is most definitely broken. From the command line, it seems to indicate all is well. And the certs appear to increment to the next number. But the certs themselves are not actually updated. I had to manually delete all the subdirectories under

 /etc/letsencrypt/ # (except the account directory)

and then

letsencrypt certonly --standalone --domains --email --account taecuau033tbutabur3u30cub3u3 --quiet

Things seem to work fine and I got an update cert after that


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.