We are happy to announce that Vesta is back under active development as of 25 February 2024. We are working on v1 candidate and expect to engage more with the community over the coming months. We are committed to open source, and we encourage contributors to help us build the future of Vesta.
LetsEncrypt Error: Invalid response from http://mydomain.com/.well-known/acme-challenge/###: \
LetsEncrypt Error: Invalid response from http://mydomain.com/.well-known/acme-challenge/###: \
Hi there,
Hopefully this will help anyone who's in the same position I was. Had some headaches getting LetsEncrypt GUI to work on apache/nginx set up and couldn't find anything on the forum that specifically addressed the issue. I wrote a blog post about it here, but I'll copy and paste the text:
-----------------------
I’d been running LetsEncrypt manually on VestaCP for some time before they implemented it natively into the control panel graphical user interface. However, at this point, if my certificates expired, once renewed, they were no longer being recognised (or rather, implemented properly). Naturally, I tried the new GUI interface for enabling LetsEncrypt, the result of which:
[picture]
Invalid response from http://mydomain.com/.well-known/acme-challenge/###: \
Please note that if you are getting an error message that has a bit more content than ‘\’, you may be encountering a different issue, and so this won’t work.
Also worth noting is that looking at the logs (‘View Logs’ in Web tab). In one case for me the LetsEncrypt server was landing on the server to make the challenge, but a webroot directory was returning a 404 and not the domain.com/.well-known/acme-challenge/ address you would expect. For a different domain, the LetsEncrypt server did seem to access what it needed, but the same error was returned.
I went down many garden paths trying to fix this, ranging from checking the permissions of the .well-known/acme-challenge directory (worth doing), placing a file in that folder to make sure it was accessible, to manually editing Apache configuration files, and so on.
Turns out the cause of the issue, at least in my case, is that proxy support must be enabled (I am using nginx):
[picture]
As you can see, it’s crossed out in this case — and you do not have the option to enable it after already creating the web project.
Therefore, the two ways around the issue:
1. Remove and re-add the website to Vesta, with Proxy support enabled this time. Backup your content, as it will be removed completely. Then re-upload/deploy your content.
2. Preferably, if you have access to the admin account (or know someone who does), log in as admin, then in the users tab, login as the user the website belongs to. When you go to edit the domain in the web tab this time, the option to enable Proxy Support is now there:
[picture]
Enable proxy support and save — don’t try to do everything at the same time. After proxy support is successfully enabled, then enable SSL Support and Lets Encrypt Support and save. It should now hopefully have successfully saved.
Hopefully this will help anyone who's in the same position I was. Had some headaches getting LetsEncrypt GUI to work on apache/nginx set up and couldn't find anything on the forum that specifically addressed the issue. I wrote a blog post about it here, but I'll copy and paste the text:
-----------------------
I’d been running LetsEncrypt manually on VestaCP for some time before they implemented it natively into the control panel graphical user interface. However, at this point, if my certificates expired, once renewed, they were no longer being recognised (or rather, implemented properly). Naturally, I tried the new GUI interface for enabling LetsEncrypt, the result of which:
[picture]
Invalid response from http://mydomain.com/.well-known/acme-challenge/###: \
Please note that if you are getting an error message that has a bit more content than ‘\’, you may be encountering a different issue, and so this won’t work.
Also worth noting is that looking at the logs (‘View Logs’ in Web tab). In one case for me the LetsEncrypt server was landing on the server to make the challenge, but a webroot directory was returning a 404 and not the domain.com/.well-known/acme-challenge/ address you would expect. For a different domain, the LetsEncrypt server did seem to access what it needed, but the same error was returned.
I went down many garden paths trying to fix this, ranging from checking the permissions of the .well-known/acme-challenge directory (worth doing), placing a file in that folder to make sure it was accessible, to manually editing Apache configuration files, and so on.
Turns out the cause of the issue, at least in my case, is that proxy support must be enabled (I am using nginx):
[picture]
As you can see, it’s crossed out in this case — and you do not have the option to enable it after already creating the web project.
Therefore, the two ways around the issue:
1. Remove and re-add the website to Vesta, with Proxy support enabled this time. Backup your content, as it will be removed completely. Then re-upload/deploy your content.
2. Preferably, if you have access to the admin account (or know someone who does), log in as admin, then in the users tab, login as the user the website belongs to. When you go to edit the domain in the web tab this time, the option to enable Proxy Support is now there:
[picture]
Enable proxy support and save — don’t try to do everything at the same time. After proxy support is successfully enabled, then enable SSL Support and Lets Encrypt Support and save. It should now hopefully have successfully saved.