Lego renew with --tls fails silently

I’ll try and run the support tool later today, out of time ATM.

support bundle code: 085c8503-62e7-cc44-5a92-377197b65f63

Also, my boss has asked that I genericize the email/server name info. Is there a way to edit the original post?

Hi @silver.bowen,

I’ve anonymized the email in your original reply. Regarding the issue, could you try the following command:

sudo /opt/bitnami/letsencrypt/lego --path="/opt/bitnami/letsencrypt" --email="YOURMAIL" --domains="YOURDOMAIN" renew

Replacing the placeholders with your email and domain?


Please, click on :heart: if you think my answer was helpful

Thanks Michiel.

$ ls -lart /opt/bitnami/letsencrypt/lego
ls: cannot access ‘/opt/bitnami/letsencrypt/lego’: No such file or directory

$ sudo ls -lart /opt/bitnami/letsencrypt
ls: cannot access ‘/opt/bitnami/letsencrypt’: No such file or directory

The certificates were original installed (and have been reinstalled a few times) using the alternative approach at: https://docs.bitnami.com/azure/how-to/generate-install-lets-encrypt-ssl/ I don’t have the auto-config script. I have tried variations like sudo lego --path"…" etc. And doing a run command to create new certs works fine, as does list. It’s only renewals that are silently failing.

Sorry, I gave the wrong lego path. In your case it should be /usr/local/bin/lego. The --tls option is required only recently and maybe your lego client is older. Can you try to update it:

cd /tmp
curl -s https://api.github.com/repos/xenolf/lego/releases/latest | grep browser_download_url | grep linux_amd64 | cut -d '"' -f 4 | wget -i -
tar xf lego_vX.Y.Z_linux_amd64.tar.gz
sudo mv lego /usr/local/bin/lego

And then execute the command again:

sudo /usr/local/bin/lego --tls --email="example@company.com" --domains="solutions-tst.opensymmetry.com" --path="/etc/lego" renew

Regards,
Michiel D’Hont


Please, click on :heart: if you think my answer was helpful

$ sudo lego -v
lego version 2.1.0 linux/amd64

I updated Lego a couple days ago. The certificates were generated with the --tls flag. I have re-updated anyway. Results of re-updating and running commands below. As you can see, the certs were not renewed and no error message was thrown.

$ cd /tmp
$ curl -s https://api.github.com/repos/xenolf/lego/releases/latest | grep browser_download_url | grep linux_amd64 | cut -d '"' -f 4 | wget -i -
--2019-02-07 14:08:28--  https://github.com/xenolf/lego/releases/download/v2.1.0/lego_v2.1.0_linux_amd64.tar.gz
Resolving github.com (github.com)... 140.82.118.3, 140.82.118.4
Connecting to github.com (github.com)|140.82.118.3|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://github-production-release-asset-2e65be.s3.amazonaws.com/37038121/2489ae80-2031-11e9-9881-ada4238d2c4b?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20190207%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20190207T140829Z&X-Amz-Expires=300&X-Amz-Signature=881f6b4b8ec588e819915a414544c3cd7f2a4c451c0f25bb22dc70c7ee2f62fa&X-Amz-SignedHeaders=host&actor_id=0&response-content-disposition=attachment%3B%20filename%3Dlego_v2.1.0_linux_amd64.tar.gz&response-content-type=application%2Foctet-stream [following]
--2019-02-07 14:08:29--  https://github-production-release-asset-2e65be.s3.amazonaws.com/37038121/2489ae80-2031-11e9-9881-ada4238d2c4b?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20190207%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20190207T140829Z&X-Amz-Expires=300&X-Amz-Signature=881f6b4b8ec588e819915a414544c3cd7f2a4c451c0f25bb22dc70c7ee2f62fa&X-Amz-SignedHeaders=host&actor_id=0&response-content-disposition=attachment%3B%20filename%3Dlego_v2.1.0_linux_amd64.tar.gz&response-content-type=application%2Foctet-stream
Resolving github-production-release-asset-2e65be.s3.amazonaws.com (github-production-release-asset-2e65be.s3.amazonaws.com)... 52.216.21.251
Connecting to github-production-release-asset-2e65be.s3.amazonaws.com (github-production-release-asset-2e65be.s3.amazonaws.com)|52.216.21.251|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 7567526 (7.2M) [application/octet-stream]
Saving to: ‘lego_v2.1.0_linux_amd64.tar.gz’

lego_v2.1.0_linux_amd64.tar.gz                 100%[==================================================================================================>]   7.22M  11.8MB/s    in 0.6s    

2019-02-07 14:08:30 (11.8 MB/s) - ‘lego_v2.1.0_linux_amd64.tar.gz’ saved [7567526/7567526]

FINISHED --2019-02-07 14:08:30--
Total wall clock time: 1.6s
Downloaded: 1 files, 7.2M in 0.6s (11.8 MB/s)
$ tar xf lego_v2.1.0_linux_amd64.tar.gz
$ sudo mv lego /usr/local/bin/lego
$ sudo /usr/local/bin/lego --tls --email="example@company.com" --domains="example.company.com" --path="/etc/lego" renew           
$ sudo ls -lart /etc/lego/certificates
total 28
drwx------ 2 root root 4096 Jan 29 15:42 .lego
-rw------- 1 root root 1679 Feb  5 16:05 example.company.com.key
-rw------- 1 root root  251 Feb  5 16:05 example.company.com.json
-rw------- 1 root root 1648 Feb  5 16:05 example.company.com.issuer.crt
-rw------- 1 root root 3600 Feb  5 16:05 example.company.com.crt
drwx------ 3 root root 4096 Feb  5 16:05 .
drwx------ 5 root root 4096 Feb  7 14:11 ..

A colleague will contact you soon to help you with this issue.

Thanks you, Michiel.

Hi,

How long did the /usr/local/bin/lego command take? Could you execute this command?

sudo ls -l /usr/local/bin/lego*

This will help us see if the executable is ok

Best regards,

Javier J. Salmerón


Was my answer helpful? Click on :heart:

Thanks for the help, Javier.

$ time sudo /usr/local/bin/lego --tls --email="example@company.com" --domains="example.company.com" --path="/etc/lego" renew

real    0m2.393s
user    0m0.091s
sys     0m0.040s

$ sudo ls -l /usr/local/bin/lego*

-rwxr-xr-x 1 bitnami bitnami 24585760 Jan 24 22:34 /usr/local/bin/lego

$ lego -v

lego version 2.1.0 linux/amd64

Hi,

This is strange, I would expect the command to provide some output. However, let us do another small test. Could you try moving the contents of the certificates folder to see if it creates new ones?

sudo mv /etc/lego/certificates /tmp
sudo /usr/local/bin/lego --tls --email="example@company.com" --domains="example.company.com" --path="/etc/lego" renew           

Maybe it is skipping for some reason and moving the folder causes to correctly create the new certificates.

Best regards,

Javier J. Salmerón


Was my answer helpful? Click on :heart:

Sorry it took me a few days to get back to this. I s=moved the certificates, stopped apache, ran the renew command. error is that certificates folder doesn’t exist. Maybe you meant run rather than renew?

 $ sudo /opt/bitnami/ctlscript.sh stop apache
 Unmonitored apache
Syntax OK
/opt/bitnami/apache2/scripts/ctl.sh : httpd stopped
$ sudo /usr/local/bin/lego --tls  --email="example@company.com" --domains="example.company.com" --path="/etc/lego" renew
2019/02/20 19:38:21 Error while loading the certificate for domain example.company.com
    open /etc/lego/certificates/example.company.com.crt: no such file or directory
$ sudo /opt/bitnami/ctlscript.sh start apache
Syntax OK
/opt/bitnami/apache2/scripts/ctl.sh : httpd started at port 80
Monitored apache
$ sudo ls -lart /etc/lego/certificates                     
ls: cannot access '/etc/lego/certificates': No such file or directory

Hi,

Yes sorry, I was meaning to run rather than renew.

Best regards,

Javier J. Salmerón


Was my answer helpful? Click on :heart:

Full command line transcript below. Running lego run did indeed create new folder. Subsequently running renew against the new certs failed silently, as has been the case. I also gave a try at running the renewal script, which also failed silently.

$ sudo ls -lart /etc/lego/
total 28
drwx------   4 root root 4096 Aug  9  2018 accounts
-rwxr-xr-x   1 root root  235 Jan 29 16:08 renew-certificate.sh.save
drwx------   2 root root 4096 Feb  5 16:04 archives
drwx------   3 root root 4096 Feb  5 16:05 certificates
-rwxr-xr-x   1 root root  468 Feb 20 19:36 renew-certificate.sh
drwx------   5 root root 4096 Feb 20 19:45 .
drwxr-xr-x 105 root root 4096 Feb 21 06:40 ..

$ sudo mv /etc/lego/certificates /etc/lego/certificates.old

$ sudo /opt/bitnami/ctlscript.sh stop apache
Unmonitored apache
Syntax OK
/opt/bitnami/apache2/scripts/ctl.sh : httpd stopped

$ sudo /usr/local/bin/lego --tls  --email="example@company.com" --domains="example.company.com" --path="/etc/lego" run
2019/02/22 14:46:25 [INFO] [example.company.com] acme: Obtaining bundled SAN certificate
2019/02/22 14:46:26 [INFO] [example.company.com] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz/PiErx0w_TwoeES_ufUAx-hx-LqiHBo65oO8CkVZI3lA
2019/02/22 14:46:26 [INFO] [example.company.com] acme: authorization already valid; skipping challenge
2019/02/22 14:46:26 [INFO] [example.company.com] acme: Validations succeeded; requesting certificates
2019/02/22 14:46:28 [INFO] [example.company.com] Server responded with a certificate.

$ sudo ls -lart /etc/lego/                                 
total 32
drwx------   4 root root 4096 Aug  9  2018 accounts
-rwxr-xr-x   1 root root  235 Jan 29 16:08 renew-certificate.sh.save
drwx------   2 root root 4096 Feb  5 16:04 archives
drwx------   3 root root 4096 Feb  5 16:05 certificates.old
-rwxr-xr-x   1 root root  468 Feb 20 19:36 renew-certificate.sh
drwxr-xr-x 105 root root 4096 Feb 21 06:40 ..
drwx------   6 root root 4096 Feb 22 14:46 .
drwx------   2 root root 4096 Feb 22 14:46 certificates

$ sudo /usr/local/bin/lego --tls  --email="example@company.com" --domains="example.company.com" --path="/etc/lego" renew

$ sudo ls -lart /etc/lego/
total 32
drwx------   4 root root 4096 Aug  9  2018 accounts
-rwxr-xr-x   1 root root  235 Jan 29 16:08 renew-certificate.sh.save
drwx------   2 root root 4096 Feb  5 16:04 archives
drwx------   3 root root 4096 Feb  5 16:05 certificates.old
-rwxr-xr-x   1 root root  468 Feb 20 19:36 renew-certificate.sh
drwxr-xr-x 105 root root 4096 Feb 21 06:40 ..
drwx------   6 root root 4096 Feb 22 14:46 .
drwx------   2 root root 4096 Feb 22 14:46 certificates

$ sudo /etc/lego/renew-certificate.sh     
Unmonitored apache
Syntax OK
/opt/bitnami/apache2/scripts/ctl.sh : apache not running
Syntax OK
/opt/bitnami/apache2/scripts/ctl.sh : httpd started at port 80
Monitored apache

Hi,

At this point, I do not know what can cause the issue when renewing. My advice would be to ask the lego developers for more information about what the issue can be. Please let us know what they say.

https://github.com/xenolf/lego/issues

Best regards,

Javier J. Salmerón


Was my answer helpful? Click on :heart:

Thanks for the effort, anyway. I’ll go file an issue over there and see if anyone can help.

I cross posted this issue over on the lego github: https://github.com/xenolf/lego/issues/816

It turns out that lego silently changed their renewal logic. Specifically, there is a default value of 30 set to the --days argument to renew (this is new). Rather than notifiying the user that the cert is till good for more than 30 days, and thus won’t be renewed, the request fails silently. The solution is to upgrade lego to at least version 2.2.0 (available 27 days ago as of this post) and to pass a --days argument with a value greater than the current number of days before the certs expire. Sample code below.

#!/bin/bash
sudo /opt/bitnami/ctlscript.sh stop apache
#
sudo /usr/local/bin/lego --tls \
--email="sample@company.com" \
--domains="sample.company.com" \
--path="/etc/lego" renew \
--days 90
#
sudo /opt/bitnami/ctlscript.sh start apache
2 Likes

Hi,

Thanks for letting us know! :slight_smile: I’m sure this will help lots of users in the community. If you find any other issues, do not hesitate to open a new thread

Best regards,

Javier J. Salmerón


Was my answer helpful? Click on :heart: