The certbot-auto renew that doesn't

Hi.
Reason I’m writing is that the output of the certbot indicates that the certificate was renewed. When I ran it again, I got urn:acme:error:rateLimited. This is especially weird bcz I’ve set the crontab to run /usr/local/bin/certbot-auto renew --quiet --no-self-upgrade twice a day as indicated per LetsEncrypt manual. I don’t know how to fix this. Before and after the process, /etc/letsencrypt/live/silversound-das-duo.de/cert.pem shows a past notAfter.

openssl x509 -enddate -noout -in silversound-das-duo.de/cert.pem 
notAfter=Sep 25 05:11:00 2017 GMT

My domain is: silversound-das-duo.de

I ran this command: /usr/local/bin/certbot-auto renew

It produced this output:

-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/silversound-das-duo.de.conf
-------------------------------------------------------------------------------
Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator nginx, Installer nginx
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for silversound-das-duo.de
tls-sni-01 challenge for www.silversound-das-duo.de
nginx: [warn] conflicting server name "silversound-das-duo.de" on 0.0.0.0:443, ignored
Waiting for verification...
Cleaning up challenges

-------------------------------------------------------------------------------
new certificate deployed with reload of nginx server; fullchain is
/etc/letsencrypt/live/silversound-das-duo.de/fullchain.pem
-------------------------------------------------------------------------------

My web server is (include version): nginx @ 1.10.3-1~dotdeb+7.1

The operating system my web server runs on is (include version): wheezy

My hosting provider, if applicable, is: a datacenter. We own physical.

I can login to a root shell on my machine (yes or no, or I don’t know): yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): hell no

openssl s_client -connect silversound-das-duo.de:443 -servername silversound-das-duo.de
returns silversound-das-duo.de cert
BUT
openssl s_client -connect www.silversound-das-duo.de:443 -servername www.silversound-das-duo.de
returns dietle-touring.de cert

Probably why the error message:

OOPS! well I fixed this, thanks, but this doesn’t explain why the certbot runs claiming all’s ok and renewed when the cert is already expired.

Nonetheless, the certs are getting issued:

https://crt.sh/?Identity=%silversound-das-duo.de&iCAID=16418

Can you show us the output of this command?

ls -l /etc/letsencrypt/*/*das-duo*

I’d like to see:
grep renewal /var/log/letsencrypt/letsencrypt.log*

Found one in the /archive that looks promising.

11:00 ~ $ ls -l /etc/letsencrypt/*/*das-duo*
-rw-r--r-- 1 root root  424 Jun 23 18:31 /etc/letsencrypt/dhparams/silversound-das-duo.pem
-rw-r--r-- 1 root root  511 Sep 26 13:39 /etc/letsencrypt/renewal/silversound-das-duo.de.conf

/etc/letsencrypt/archive/silversound-das-duo.de:
total 32
-rw-r--r-- 1 root root 1854 Jun 23 17:48 cert1.pem
-rw-r--r-- 1 root root 1854 Sep 26 13:39 cert2.pem
-rw-r--r-- 1 root root 1647 Jun 23 17:48 chain1.pem
-rw-r--r-- 1 root root 1647 Sep 26 13:39 chain2.pem
-rw-r--r-- 1 root root 3501 Jun 23 17:48 fullchain1.pem
-rw-r--r-- 1 root root 3501 Sep 26 13:39 fullchain2.pem
-rw-r--r-- 1 root root 1704 Jun 23 17:48 privkey1.pem
-rw-r--r-- 1 root root 1704 Sep 26 13:39 privkey2.pem

/etc/letsencrypt/archive/silversound-das-duo.de-0001:
total 16
-rw-r--r-- 1 root root 1854 Jun 27 08:10 cert1.pem
-rw-r--r-- 1 root root 1647 Jun 27 08:10 chain1.pem
-rw-r--r-- 1 root root 3501 Jun 27 08:10 fullchain1.pem
-rw-r--r-- 1 root root 1704 Jun 27 08:10 privkey1.pem

/etc/letsencrypt/live/silversound-das-duo.de:
total 4
-rw-r--r-- 1 root root 543 Jun 27 08:10 README
lrwxrwxrwx 1 root root  51 Sep 26 13:39 cert.pem -> ../../archive/silversound-das-duo.de-0001/cert1.pem
lrwxrwxrwx 1 root root  52 Sep 26 13:39 chain.pem -> ../../archive/silversound-das-duo.de-0001/chain1.pem
lrwxrwxrwx 1 root root  56 Sep 26 13:39 fullchain.pem -> ../../archive/silversound-das-duo.de-0001/fullchain1.pem
lrwxrwxrwx 1 root root  54 Sep 26 13:39 privkey.pem -> ../../archive/silversound-das-duo.de-0001/privkey1.pem
11:00 ~ $ 
11:00 ~ $ cd /etc/letsencrypt/archive/
11:01 archive $ openssl x509 -enddate -noout -in silversound-das-duo.de/cert1.pem 
notAfter=Sep 21 14:49:00 2017 GMT
11:01 archive $ openssl x509 -enddate -noout -in silversound-das-duo.de/cert2.pem 
notAfter=Dec 25 10:40:00 2017 GMT

Maybe I was looking in the wrong directory? Can it be that the “cert2” was properly signed and created but not symlinked into /live? I’m a bit confused.

That suggests a bug in Certbot; could you post the associated log from /var/log/letsencrypt somewhere?

It does seem like the cert2.pem is your new certificate, and normally Certbot should have updated the symlink from live to point to it.

/etc/letsencrypt/live/silversound-das-duo.de/ should have symlinks to the files in /etc/letsencrypt/archive/silversound-das-duo.de/ but instead it has symlinks to /etc/letsencrypt/archive/silversound-das-duo.de-0001/.

Did you rename the directory some time ago? If so, the symlinks need to be adjusted, or else Certbot gets confused like this.

The "certbot update_symlinks" command may be able to fix it. (I'm not sure which types of issues it's able to handle.) You may have to delete the erroneous symlinks first. You may have to recreate them by hand with ln.

Oh, I didn’t notice the cross-lineage links—thanks for reading more attentively, @mnordhoff!

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