Problem renewing certificate


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

My domain is:

I ran this command: /opt/letsencrypt/letsencrypt-auto renew

It produced this output:

0 upgraded, 0 newly installed, 0 to remove and 75 not upgraded.
3 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale (“C”).
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
Setting up nginx-common (1.8.1-1+trusty0) …
cp: cannot create regular file ‘/var/www/html/index.nginx-debian.html’: No such file or directory
dpkg: error processing package nginx-common (–configure):
subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of nginx-full:
nginx-full depends on nginx-common (= 1.8.1-1+trusty0); however:
Package nginx-common is not configured yet.

dpkg: error processing package nginx-full (–configure):
dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of nginx:
nginx depends on nginx-full (>= 1.8.1-1+trusty0) | nginx-light (>= 1.8.1-1+trusty0) | nginx-extras (>= 1.8.1-1+trusty0); however:
Package nginx-full is not configured yet.
Package nginx-light is not installed.
Package nginx-extras is not installed.
nginx depends on nginx-full (<< 1.8.1-1+trusty0.1~) | nginx-light (<< 1.8.1-1+trusty0.1~) | nginx-extras (<< 1.8.1-1+trusty0.1~); however:
Package nginx-full is not configured yet.
Package nginx-light is not installed.
No apport report written because the error message indicates its a followup error from a previous failure.
Package nginx-extras is not installed.

dpkg: error processing package nginx (–configure):
dependency problems - leaving unconfigured
No apport report written because the error message indicates its a followup error from a previous failure.
Errors were encountered while processing:
E: Sub-process /usr/bin/dpkg returned an error code (1)

My web server is (include version):

Ubuntu 14.04.4 LTS (GNU/Linux 3.13.0-71-generic x86_64)
Running on NGINX.

My hosting provider, if applicable, is:

Digital Ocean

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

Yes. But I’m really noob when it comes to server stuff. =(
Followed a tutorial on Digital Ocean to set up letsencrypt. It worked for awhile till it expired.

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

Cert not renewing again

it looks like you have a number of issues there, probably most by the issue of packages that need updating. Can you SSH into the server and run;

sudo apt-get update

which should get an updated list of packages, then

sudo apt-get upgrade

which should update all the packages that need updating. I suspect you will get an error on this second command, can you paste the results of that please.


Hi! Thanks for your reply!
This is what I got after update and upgrade,

Reading package lists… Done
Building dependency tree
Reading state information… Done
Calculating upgrade… Done
The following packages have been kept back:
linux-generic linux-headers-generic linux-image-generic
0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.


great - that looks much better than your previous

If you run

/opt/letsencrypt/letsencrypt-auto renew

again now, do you get exactly the same response ? hopefully at least the errors will be reduced. If you still see the “perl locale errors” can you run the following lines

sudo locale-gen "en_US.UTF-8"
sudo dpkg-reconfigure locales

and then run

/opt/letsencrypt/letsencrypt-auto renew

again, pasting the output that you get.


Hmm… It seems that the renew is successful. Yay!
But the site still seems to have expired certs… Not sure why.


Yup, the CT logs show Let’s Encrypt issued a new certificate for that name, but your server isn’t presenting it.

You need to dig into the nginx configuration for your server, and figure out how it’s pointing to old certificates. Hopefully you wrote some of that config because I think the certbot / letsencrypt software doesn’t know how to do that for nginx by default. One thing I’d look for is if you’ve got paths that don’t start /etc/letsencrypt/live but instead maybe /etc/letsencrypt/keys or something - the “live” directory will get updated with renewed certificates, whereas in other directories it keeps old versions around for your records, so you want to use the “live” directory in server config.

Hope that helps, otherwise maybe a nginx person can chime in


I did a check with sudo ls -l /etc/letsencrypt/live/
And the result is

total 0
lrwxrwxrwx 1 root root 38 Jun 27 22:50 cert.pem -> …/…/archive/
lrwxrwxrwx 1 root root 39 Jun 27 22:50 chain.pem -> …/…/archive/
lrwxrwxrwx 1 root root 43 Jun 27 22:50 fullchain.pem -> …/…/archive/
lrwxrwxrwx 1 root root 41 Jun 27 22:50 privkey.pem -> …/…/archive/

Is it because the names now have a 2 behind it instead of the original xxx.pem?
Will each renew add a new number behind?
So I have to update my config after each update?

That is the configuration mentioned right? Or am I got the wrong action required?


The short answer to these is no.

This is where the certificates are, and the files you show ( in /etc/letsencrypt/live/ ) should always correctly point to the latest files. You need to check in the nginx configuration for your server (typically /etc/nginx/nginx.conf ) and see which certificates that points to ( it should be the ones in /etc/letsencrypt/live/ )


I’ve followed,

to set up the initial ssl which didn’t seem to get me to edit any nginx config,

I tried the /etc/nginx/nginx.conf you suggested but didn’t see any pointing to any certs though.
Not sure how to add it too. =(

If it is editing the /etc/nginx/sites-available/,
it seems to be pointing correctly,
ssl_certificate /etc/letsencrypt/live/;
ssl_certificate_key /etc/letsencrypt/live/;


have you reloaded or restarted nginx ( service reload nginx or service restart nginx ) ?


Yup, I did quite a few sudo service nginx restart.

When I tried sudo service nginx reload, it says reload: Job is not running: nginx.


Id does seem as if there is something wrong in the nginx config then. If you run

grep -R ssl_ /etc/nginx

does it only list the

ssl_certificate /etc/letsencrypt/live/;
ssl_certificate_key /etc/letsencrypt/live/;

or does it link the older certs anywhere ?


Running that command loads a whole list of stuff as I have a few sites hosted on the server, all SSL not working too btw, but here is the gist of those that return

/etc/nginx/sites-available/ ssl_certificate /etc/letsencrypt/live/;
/etc/nginx/sites-available/ ssl_certificate_key /etc/letsencrypt/live/;
/etc/nginx/sites-available/ ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
/etc/nginx/sites-available/ ssl_prefer_server_ciphers on;
/etc/nginx/sites-available/ ssl_dhparam /etc/ssl/certs/dhparam.pem;
/etc/nginx/sites-available/ ssl_ciphers xxx
/etc/nginx/sites-available/ ssl_session_timeout 1d;
/etc/nginx/sites-available/ ssl_session_cache shared:SSL:50m;
/etc/nginx/sites-available/ ssl_stapling on;
/etc/nginx/sites-available/ ssl_stapling_verify on;
/etc/nginx/sites-available/ ssl_certificate cert.pem;
/etc/nginx/sites-available/ ssl_certificate_key cert.key;
/etc/nginx/sites-available/ ssl_session_timeout 5m;
/etc/nginx/sites-available/ ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
/etc/nginx/sites-available/ ssl_ciphers “HIGH:!aNULL:!MD5 or HIGH:!aNULL:!MD5:!3DES”;
/etc/nginx/sites-available/ ssl_prefer_server_ciphers on;

This repeats itself twice too. I changed the ssl_ciphers above to xxx as I think it’s supposed to be hidden I’m guessing…


They all look fine ( and listing the ssl_ciphers is Ok )

what are the files in /etc/letsencrypt/archive/ ? I’m just wondering if for some reason the links from /etc/letsencrypt/live/ aren’t pointing to the latest version OK.

The other way to test would be using the command

openssl x509 -in /etc/letsencrypt/live/ -noout -dates

which should list the start and end date for that cert ( which should be the recent valid one, not the old expired one )


Tried running the command and it returns,
notBefore=Jun 27 13:50:00 2016 GMT
notAfter=Sep 25 13:50:00 2016 GMT
It’s the latest isn’t it? Weird… Argh.


This isn’t necessarily the most relevant approach, but you can find out whether or not your nginx process is reading the cert by running

stat /etc/letsencrypt/archive/*.pem

immediately before and after restarting nginx. One of the Access times in the output should change, and that is the file that nginx actually read (“accessed”).


Is that the exact command? Tried running it, it returns,
stat: cannot stat ‘/etc/letsencrypt/archive/*.pem’: No such file or directory

I tried running stat /etc/letsencrypt/live/ instead and the access time did change.
Access: 2016-06-28 08:23:19.878481918 +0800
Modify: 2016-06-27 22:50:30.621625248 +0800
Change: 2016-06-27 22:50:30.621625248 +0800

Access: 2016-06-29 09:13:58.077435468 +0800
Modify: 2016-06-27 22:50:30.621625248 +0800
Change: 2016-06-27 22:50:30.621625248 +0800


There seems to be some kind of inconsistency between the nginx version mentioned in your initial post:

… and the one your server reports: Server: nginx/1.10.1

This made me think that you might somehow have two instances of nginx running, and service nginx restart only restarts one of those, while the other is listening port 443 with the old certificate still in memory (not sure how nginx would handle another process on port 443). Maybe you’re using nginx both from Ubuntu’s repository and the one nginx provides for trusty?

You could easily confirm this with something like ps aux | grep nginx after doing another restart. If one of the nginx processes showing up (there’s more than one, that’s normal) has a start date that’s not from just a moment ago, this is probably your issue.


Oh my… Two instances of nginx? How did that happen…

admin 15178 0.0 0.1 11728 664 pts/0 S+ 09:46 0:00 grep --color=auto nginx
root 30389 0.0 0.5 146940 2800 ? S Jun27 0:00 nginx: master process /usr/sbin/nginx
www-data 30391 0.0 1.0 148232 5080 ? S Jun27 0:08 nginx: worker process

This is the result… Hmm…


Just to clarify, that’s right after running service nginx restart? It doesn’t seem like nginx is getting restarted at all if that’s the case (though there seems to be only one instance).

Is there any output when you run service nginx restart? How about /etc/init.d/nginx restart? Anything interesting in your nginx error log?