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.
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
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.
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?
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.
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.
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.
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.
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.