Cannot renew cert on QNAP NAS using LeGo

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: kerrzone.com

I ran this command: lego --accept-tos --email steve@kerrzone.com --tls --http.webroot /share/Web/.well-known/acme-challenge --domains kerrzone.com --domains musings.kerrzone.com --domains steppenwolf.myqnapcloud.com --key-type rsa2048 renew

It produced this output: acme: error presenting token: could not start HTTPS server for challenge: listen tcp :443: bind: permission denied

My web server is (include version): QNAP NAS built in apache

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

My hosting provider, if applicable, is: n/a self hosted

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

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): Lego 4.17.3

I am not a lego expert but it looks like you set the --tls option to use lego's built-in server for tls-alpn challenge but it is failing as Apache is already listening on port 443.

If you replace --tls with --http it will use your Apache webserver to satisfy the HTTP challenge using the http.webroot path you specified. Just make sure that webroot path matches the DocumentRoot in the receiving Apache VirtualHost. You don't include the /.well-known/acme-challenge in the .webroot value. The folder here should match the DocumentRoot folder in Apache

5 Likes

Thank-you Mike for the quick and very helpful response. I had switched to tls because http was not working with the acme validation, although all web sites work with http and https on port 80 and 443 respectively and the existing ssl cert is still valid and works. Based on your advice I slimmed down the LeGo command and switched back to http validation, unfortunately still getting validation errors.

New command I tried

lego --email steve@kerrzone.com --domains kerrzone.com --domains musings.kerrzone.com --domains steppenwolf.myqnapcloud.com --http renew

Renewal process starts and runs as expected however two of the URLs still get an error message:

2024/06/08 11:51:42 error: one or more domains had a problem:
[kerrzone.com] [kerrzone.com] acme: error presenting token: could not start HTTP server for challenge: listen tcp :80: bind: permission denied[musings.kerrzone.com] [musings.kerrzone.com] acme: error presenting token: could not start HTTP server for challenge: listen tcp :80: bind: permission denied

Interestingly the QNAP NAS site (which uses a different web server and ports) seems to validate but the two virtual web sites don't.

The site set-up is the same as when I obtained the certificate originally so I am puzzled.

Do you have any idea what these new error messages mean and how I might resolve them?

1 Like

My advice was to use --http along with --http.webroot

By leaving off the .webroot option you are telling lego to use its built-in standalone http server to handle the challenge. But, because your Apache is using port 80 the lego one cannot use that.

The error message is saying that port 80 was not available to lego's standalone.

Please review my previous post again and try those settings.

3 Likes

Thank-you for such quick responses. Actually I followed your advise initially but it did not work so I took out the /share/Web which is the document root for the virtual web server.

Here is what I tried first and the response I got.

lego --accept-tos --email steve@kerrzone.com --http --http.webroot /share/Web/ --domains kerrzone.com --domains musings.kerrzone.com --domains steppenwolf.myqnapcloud.com --key-type rsa2048 renew

[kerrzone.com] acme: error: 403 :: urn:ietf:params:acme:error:unauthorized :: 68.149.107.49: Invalid response from http://kerrzone.com/.well-known/acme-challeng e/y7bYSih1xtfguf87aj4aOOPuC301SPPjEYOG-hGB11M: 404
[musings.kerrzone.com] acme: error: 403 :: urn:ietf:params:acme:error:unauthorized :: 68.149.107.49: Invalid response from http://musings.kerrzone.com/.well-known/acme-challenge/Ta4V7RI0uPIxphqHGg4ehWDIYe7fJ_yUyv0YPx3L9ck: 404

As you indicated, no bind issue here but an acme code error and also an invalid response although the challenge url does return the site just not a valid page on the site.

Any ideas what I might try.

1 Like

The "404" is an HTTP Not Found error. It usually means the webroot path does not match the DocumentRoot in the VirtualHost.

A good place to start debugging is to show us the output of this

apache2ctl -t -D DUMP_VHOSTS

You may need to replace apache2ctl with apachectl or httpd
I don't know which one your system uses off-hand

This shows each of the VirtualHosts in effect. And, which config files they use.

2 Likes

Great advice, again thank-you your help was invaluable.

Turns out when using LeGo the first time back in April 2024 I specified http.webroot /share/Web/.well-known/acme-challenge and got my certificates although that really was not the web root for either sites.

On your prompting I found the web root for each site was a subdirectory of /share/Web and added them both to the renew command and it worked.

I am puzzled how I got the certificates in the first place with the wrong web root as it would not work for renewal It was confusing using the same command as initially with renew instead of run did not work. You called it though, the webroot path needed to be altered.

I have been using let's encrypt for some years but the QNAP built in GUI stopped working for alternate sites (although still seems to work for the DDNS URL only on my other QNAP NAS's) This is why I tried the LeGO app on one server in April so I could get one cert for three URL's.

FYI on QNAP NAS none of the apache commands work so in the end I had to open httpd-vhosts-user.conf with an editor to see the config.

2 Likes

I think this explains that ...

Your command in your first post also had --tls. That sets up the lego built-in server to handle port 443 and a TLS-ALPN challenge. That failed now because Apache is now using that port for HTTPS.

But, perhaps that port was free originally. You didn't have a cert yet so seems reasonable that Apache wasn't configured to use port 443 for HTTPS (which requires a cert).

As long as the lego TLS-ALPN challenge worked it did not matter that the http.webroot was wrong. Satisfying that challenge was enough to get the cert.

I suppose this is mostly academic since you are now working. Just thought it might be helpful.

3 Likes