Keywords: WordPress - AWS - Technical issue - Secure Connections (SSL/HTTPS)
I have had a heck of a time with trying to get auto-renewal working with my Lego Letsencrypt certificates. I can manually renew certificates, but I’ve yet to figure out what is stopping my cronjob from renewing them for me. Here’s what I’ve tried so far today:
Downloaded latest lego version 2.2.0
Installed it, and then had to do a fresh ‘run’ command for the backwards incompatibility with --tls
That worked and I got new certificates. All is well.
Verified that my /etc/lego/renew-certificate.sh file is correct
Ran sudo chmod +x /etc/lego/renew-certificate.sh
Then I try to run sudo /etc/lego/renew-certificate.sh and the output says:
No help topic for ‘path=/etc/lego’
And no renewal. Obviously it won’t run automatically if it doesn’t run manually, so this is my stumbling block. Any advice or additional things I can check? I think I’ve read every similar post on this forum to no avail. Thanks!
Keywords: WordPress - AWS - Technical issue - Secure Connections (SSL/HTTPS)
Found the answer to that immediate problem. Forgot the – before path. Ooops
Now the output looks like this
itnami@ip-172-26-11-31:/$ sudo /etc/lego/renew-certificate.sh
/opt/bitnami/apache2/scripts/ctl.sh : httpd stopped
/opt/bitnami/apache2/scripts/ctl.sh : httpd started at port 80
Looking at the last edit on the certificate files, they’re not being updated. Shouldn’t I see some output from the renew request?
can you check the expiration date of the certificate using your web browser? You will need to obtain the certificate’s information. If it’s not updated, we have a Support Tool that will gather relevant information for us to analyze your configuration. Could you please download and execute it on the machine where the stack is running by following the steps described in the guide below?
Please note that you need to paste the code outputted by the tool in your reply.
I had to install the support tool, but got that all working now. Good to have in the future.
I ran the renew-certificate.sh now and got the same non-output. I thought maybe it wasn’t running because my certs weren’t outdated enough? But it did not update them just now, they still show March 9 timestamp in the browser.
I just checked that Apache is using valid certificates and your website is also showing the certificates information properly
lrwxrwxrwx 1 root root 44 Mar 9 21:35 server.crt -> /etc/lego/certificates/****ontrols.com.crt lrwxrwxrwx 1 root root 44 Mar 9 21:35 server.key -> /etc/lego/certificates/****controls.com.key
As you can see the certificate files are symbolic links that use the files inside the /etc/lego folder. Those certificates also include the www domain (www.****controls.com). Could you please share with us the content of the
/etc/lego/renew-certificate.sh file? You can hide your email and domains if you want. Apart from that, can you manually run the
lego command inside that script and share the output with us?
So far that all looks correct, right? Here is the content of my file /etc/lego/renew-certificate.sh
#!/bin/bash sudo /opt/bitnami/ctlscript.sh stop apache sudo /usr/local/bin/lego --tls --email="firstname.lastname@example.org" --domains="*****controls.com" --domains="www.*****controls.com" --path="/etc/lego" renew sudo /opt/bitnami/ctlscript.sh start apache
If I run the commands inside the file, this is what I get (the same non-output that running the file produces):
bitnami@ip-172-26-11-31:~$ sudo /opt/bitnami/ctlscript.sh stop apache Unmonitored apache Syntax OK /opt/bitnami/apache2/scripts/ctl.sh : httpd stopped bitnami@ip-172-26-11-31:~$ sudo /usr/local/bin/lego --tls --email="email@example.com" --domains="*****controls.com" --domains="www.*****controls.com" --path="/etc/lego" renew bitnami@ip-172-26-11-31:~$ sudo /opt/bitnami/ctlscript.sh start apache Syntax OK /opt/bitnami/apache2/scripts/ctl.sh : httpd started at port 80 Monitored apache
If I run the commands as per the manual renewal instructions (without /usr/local/bin/ defined) then it will work. That’s how I’ve been updating thus far but I didn’t do so we could still see the old certs in place. Does this point to some permission for that user not being set properly?
Do you mean these certificates?
lrwxrwxrwx 1 root root 44 Feb 5 20:24 server.crt.old -> /etc/lego/certificates/****controls.com.crt lrwxrwxrwx 1 root root 44 Feb 5 20:24 server.key.old -> /etc/lego/certificates/****controls.com.key
Don’t worry about them. Apache is not using the .old files. You can simply remove them by running this command (it won’t remove the original files inside /etc/lego)
sudo rm -rf /opt/bitnami/apache2/conf/server.*.old
Happy to help!
Was my answer helpful? Click on
Thanks for advice on how to clear out the “old” old certs. I was actually referring to the “current” certs having the old time stamp:
bitnami@ip-172-26-11-31:~$ sudo ls -la /etc/lego/certificates total 40 drwx------ 2 root root 4096 Feb 5 20:21 . drwx------ 4 root root 4096 Mar 9 21:47 .. -rw------- 1 root root 3596 Mar 9 21:32 *****controls.com.crt -rw------- 1 root root 1648 Mar 9 21:32 *****controls.com.issuer.crt -rw------- 1 root root 238 Mar 9 21:32 *****controls.com.json -rw------- 1 root root 1675 Mar 9 21:32 *****controls.com.key
Those are all marked with the March 9 timestamp from the last time I manually ran the renew command. Shouldn’t I see those timestamps update every time I’ve run a test of the renew-certificate.sh if it was working?
It seems that the certificates were not renewed properly. Can you let us know the lego version you have?
Version is 2.1.0. One of the first troubleshooting steps I did was to do a fresh install of the latest, upgrading my original version.
bitnami@ip-172-26-11-31:~$ /usr/local/bin/lego --version lego version 2.1.0 linux/amd64 bitnami@ip-172-26-11-31:~$ lego --version lego version 2.1.0 linux/amd64
Not sure if this is pertinent, but it only fails when I define /usr/local/bin/lego in the prompt. If I just do “lego” by itself instead, it will update the certs. I thought maybe I had two different versions installed like some other threads on here, but the versions line up when I run the version command either way.
Maybe a stupid question, but can I just remove the /usr/local/bin/ designation from my cronjob or will it fail for sure then?
Hi @david.fisher, just to be sure, don’t you have a lego in /opt/bitnami? If so could you run this?
sudo /opt/bitnami/letsencrypt/lego --version
In any case, you mention /usr/local/bin/lego does not work. What output do you get when you run this?
I do get a version back from the /opt/bitnami lego as well - same 2.2.0
bitnami@ip-172-26-11-31:~$ sudo /opt/bitnami/letsencrypt/lego --version lego version 2.2.0 linux/amd64
Here’s the output of the which lego command
bitnami@ip-172-26-11-31:~$ which lego /usr/local/bin/lego
Oh wait, I’m wrong. It’s not the same.
/opt/bitnami/letsencrypt/lego is at 2.2.0
/usr/local/bin/lego is at 2.1.0
Do I need to update the cronjob to use /opt/bitnami/letsencrypt/lego since that seems to be the one I upgraded to the latest version?
Hi @david.fisher, could you try that lego binary instead?
Note that it is possible the certificate is not getting renewed because it is already valid. You can check that with this command:
sudo /opt/bitnami/letsencrypt/lego --path="/opt/bitnami/letsencrypt" list
If there’s still significant time pending before it gets renewed, it’s possible Lego is not renewing it again because it’s still valid.
When I do that command in the bitnami/letsencrypt directory, it doesn’t find any certificates.
bitnami@ip-172-26-11-31:~$ sudo /opt/bitnami/letsencrypt/lego --path="/opt/bitnami/letsencrypt" list No certificates found.
If I do the same thing with usr/local then it does find the certificate issued on March 9 that combined the root domain with www subdomain, as well as an older cert that was just for the www subdomain issued late 2018 before I knew to combine them.
bitnami@ip-172-26-11-31:/$ sudo /usr/local/bin/lego --path="/etc/lego" list Found the following certs: Certificate Name: *****controls.com Domains: *****controls.com, www.*****controls.com Expiry Date: 2019-06-07 20:27:29 +0000 UTC Certificate Path: /etc/lego/certificates/*****controls.com.crt Certificate Name: www.*****controls.com Domains: www.*****controls.com Expiry Date: 2018-09-28 18:28:08 +0000 UTC Certificate Path: /etc/lego/certificates/www.*****controls.com.crt
If it’s not apparent, I’m not deeply familiar personally with what I’m doing. I just follow the instructions in the Bitnami docs but I don’t fully understand why the latest version of Lego is available in the bitnami directory but not in the location where I installed it following the instructions. I thought maybe I’d check the latest version and try again, but those commands aren’t working for me this morning.
bitnami@ip-172-26-11-31:/tmp$ curl -s https://api.github.com/repos/xenolf/lego/releases/la test | grep browser_download_url | grep linux_amd64 | cut -d '"' -f 4 | wget -i - No URLs found in -.
I’m inclined to wait until until the first of April to see if the script will run successfully, as I’m not sure what else to check. I’m hoping it’s just because the certs have to be sufficiently close to expiration before they will renew, unless you see anything else here I can try to troubleshoot.
Thanks for your help!!
Incidentally, I did another round of googling for lego version 2.1.0 and failing silently thinking maybe 2.1.0 couldn’t handle the --tls argument and I needed to work to upgrade to 2.2.0. I found this post on this community:
So that’s sounding like maybe I do just need to wait until my certificates are within 30 days of expiration, or update to 2.2.0 and force the parameter to something shorter (but I don’t think that’s necessary).
It does mean that I should run the cronjob every 30 days or on the 1st of every month instead of on the 31st of every month like I was considering (since that happens almost every other month and I figured why run more often than needed - now I know).
That also means my certs won’t update on April 1 either because they’ll have more than 30 days remaining, so I’ll have to wait until June 1 to see if everything is working.
Thanks for pointing that out @david.fisher!
As for the renewal, even though certificates have a duration of 3 months, it is recommended to renew them every 60 days, and if any issues occur, you have the 30 days for fixing it.
Unfortunately it’s a slow process, but the good part is if your e-mail is well configured, you should get an alert reminding you to update the certificates.
If you find any issues in the next run let us know and we’ll do our best to help!
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.