Let's Encrypt says it renewed, but it didn't


#1

I can renew my certificate with the le-renew-webroot command, and it reports that all is well, and my certificate is renewed. But it didn’t actually work as evidenced by the fact that I can run the le-renew-webroot command again, and it says my certificate is out of date, it will renew it, and it is successful. Chrome to https://www.slaney.org also reports that the site does not have a valid certificate. This worked when I first set it up, but I can’t seem to renew.

Help?

Thanks.

– Malcolm

Please fill out the fields below so we can help you better.

My domain is: slaney.org

I ran this command: sudo /usr/local/sbin/le-renew-webroot

It produced this output:

Checking expiration date for slaney.org
The certificate for slaney.org is about to expire soon. Starting webroot renewal script…
IMPORTANT NOTES:

  • Congratulations! Your certificate and chain have been saved at
    /etc/letsencrypt/live/slaney.org-0002/fullchain.pem. Your cert will
    expire on 2016-10-09. 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"
  • If you like Certbot, please consider supporting our work by:
    Donating to ISRG / Let’s Encrypt: https://letsencrypt.org/donate
    Donating to EFF: https://eff.org/donate-le
    Reloading nginx
  • Reloading nginx configuration nginx [ OK ]
    Renewal process finished for domain slaney.org

My operating system is (include version): Ubuntu 14.04.4 LTS

My web server is (include version): nginx version: nginx/1.4.6 (Ubuntu)

My hosting provider, if applicable, is: Google cloud

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): no


#2

Did you remember to reload or restart nginx so that it uses the new cert?


#3

Yes, that is part of the script.
Rebooting didn’t help either.


#4

@cool110 it does say right in that output “reloading nginx configuration”, so probably yes?

This part suggests your system has at least two different certificates issued for slaney.org and it is possible that your server is using one, while the renewals are occurring for a different one

Check whether the nginx configuration mentions the same file as the renewal message, and it’d also be worth figuring out why you have two (or more) certificate hierarchies, which could involve remembering back to when you first signed up to Let’s Encrypt and maybe experiments you abandoned while figuring out how to use it.


#5

Yes, there are two certificates in the fullchain.pem file you mentioned!

How do I recover?

– Malcolm
P.S. And yes, there was some experimentation involved when I first set it up. But that was a long time ago and I don’t remember what I did.


#6

It’s normal for there to be two certificates in fullchain.pem, that’s not a problem. The “full chain” consists of the certificate you asked for from Let’s Encrypt, plus an “intermediate” certificate which was issued to Let’s Encrypt by a root CA, proving they’re trusted to issue your certificate. That intermediate certificate is signed by a “root” and people’s web browsers, operating systems etc. know only about the roots they trust, so they need to follow a “chain” from any other certificate to those roots. Hope that made sense.

The -0002 in the filename is a counter, that’s why I said there might be other certificates, because you know, counters don’t generally start from two :slight_smile: Can you look in the nginx configuration for mentions of fullchain.pem or privkey.pem to see if they have that -0002 in there or not ?


#7

OK, nginx only mentions fullchain and privkey, no mention of -0002.

But you are right, since I do seem to only be updating the -0002 license. This is what the live directory contains.

Should I just change nginx to point to the -0002 directory and call it a day? That sounds simple enough.

– Malcolm
root@instance-1:/etc/nginx/sites-available# grep fullchain *
default: ssl_certificate /etc/letsencrypt/live/slaney.org/fullchain.pem;
paly.slaney.org: ssl_certificate /etc/letsencrypt/live/slaney.org/fullchain.pem;

root@instance-1:/etc/letsencrypt/live# ls -lsa /etc/letsencrypt/live
total 24
4 drwx------ 6 root root 4096 May 26 03:49 .
4 drwxr-xr-x 8 root root 4096 Feb 28 20:29 …
4 drwxr-xr-x 2 root root 4096 Feb 28 21:20 paly2.slaney.org
4 drwxr-xr-x 2 root root 4096 Feb 28 20:29 slaney.org
4 drwxr-xr-x 2 root root 4096 Feb 28 21:13 slaney.org-0001
4 drwxr-xr-x 2 root root 4096 Jul 11 13:31 slaney.org-0002


#8

I think that’s a very reasonable choice. Be careful to check those nginx configuration files for any other mentions of /etc/letsencrypt/live/slaney.org in case there are more to change to point to -0002, there should be at least fullchain.pem and privkey.pem to be changed, but there could be other mentions.

However, you mentioned that when you ask to renew again, it does, and that’s still a bit concerning, maybe someone more expert in matters of certbot can chime in about that?


#9

Bingo. That worked (adding -0002 to the end of the slaney.org in the pem files). Thank you very much!!!

– Malcolm


#10

Perhaps the script is looking at slaney.org/live/cert.pem, noticing that it’s still about to expire, and running the renewal with certonly, which then actually renews slaney.org-0002/live/cert.pem instead. Then re-running the script may repeat this process.

If this is true, then @MalcolmSlaney may hit a rate limit relatively soon because the 0002 cert will get renewed over and over again unnecessarily. A possible way to work around this would be to move /etc/letsencrypt/renewal/slaney.org.conf, /etc/letsencrypt/live/slaney.org, and /etc/letsencrypt/archive/slaney.org out of /etc/letsencrypt. The same would probably have to be done with slaney.org-0001, for the same reason.

Using certbot renew instead would presumably renew all three certificates, which is unnecessary for the first two but has the advantage that it only renews any individual certificate when that particular certificate is about to expire. The le-renew-webroot script is probably trying to achieve this behavior but doesn’t work as intended when there are two different certs with exactly the same names.

This is indirectly related to https://github.com/certbot/certbot/issues/2305, which I’m working on right now, but even if I fix it, it won’t retroactively fix existing renewal scripts like that le-renew-webroot.


#11

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