I have a subdomain “adminserver.rodningenmarketing.no” which points to my virtualmin host (where I login to the virtualmin panel). I was able to request an SSL certificate from Let’s Encrypt (LE) for this subdomain twice in the past (started using virtualmin 5 months ago). This time it failed.
I have two virtual servers running:
hvalergjestehage.no
rodningenmarketing.no
Error from LE-page in virtualmin, when requesting for rodningenmarketing.no and adminserver.rodningenmarketing.no:
What’s weird is that rodningenmarketing.no seems to pass the challenge, while adminserver.rodningenmarketing.no tries to do the challenge through the other domain hvalergjestehage.no… I set rodningenmarketing as “default website for IP address” under “website options”.
I can’t remember having changed anything accross the virtualmin host since the previous LE-request 2.5 months ago. The only thing that has been changed (that I can recall) is some nginx-site config for cache. I also just did a manual LE update for hvalergjestehage.no which was approved.
Thank you for your reply. I have AWS Route53 as DNS, all domains have A records set up correctly there (including the subdomain). Is there something I’m missing?
still redirecting elsewhere, and that’s probably the reason LE can’t verify it… are you sure adminserver.rodningenmarketing.no works? is there a virtual host in nginx with this subdomain?
Simply create a symbolic link in the /var/www/html directory of the virtualmin server and point it at /home/YOURDOMAIN/public_html/.well-known
Something like this:
cd /var/www/html
ln -s /home/YOURDOMAIN/public_html/.well-known /var/www/html/.well-known
Then run the letsencrypt process again from the virtual server .
Should work. The directories may be different on your web server.
Worked for me as I had the same problem. A Virtualmin host was hostname.domain.com virtual domain for domain.com configured in virtualmin on the same machine.
Once I figured out that the virtualmin servers built in web server was answering for the virtualmin host all I had to do was create a link from teh virtualmin hosts website directory to the virtual server for the domains website directory and all was good. I could then use the same ssl with webmin postfix etc.
I added a symbolic link now, and I get the same error as before, where “hvalergjestehage.no” is responding to the LE-challenge.
I also noticed I had a folder called “ubuntu” in the home directory, could it be that I need to do something with that? Also I’m using nginx while you seemed to be using apache in your problem. I see nginx has a virtual host name “_”, which I suspect is the default virtual host…
Thank you for spotting that @dimitrist. No there’s no virtual host with that subdomain. It’s still redirecting after the symbolic link @sparticle suggested. Don’t know what to do from here.
Since virtualmin is running on the same subdomain I thought I couldn’t add a virtual server for it. Is that incorrect?
When we tried to secure the virtualmin server server.ourdomain.com from the SSL page in Webmin Configuration we got the failures you were experiencing where the letsencrypt process looks in the webroot of the virtualmin server for the .well-known and not the webroot of ourdomain.com virtual server.
By creating a symbolic link from the virtualmin servers web root (server.ourdomain.com) to the main domain virtual servers web root (ourdomain.com) it could access the .well-known directory relevant to the main domain (ourdomain.com). The Virtualmin server being a sub domain, so in the same tree.
This is the only way we could get this to work.
This particular virtualmin server is a Ubuntu 14.04 LAMP server hosting a number of clients including ourselves from our main domain.
I have a screenshot on the first post on the top of this thread, isn’t it visible?
I’ve tried adding symbolic link and also to add a location for the default nginx server with the correct root folder inside it. However, if I test with LE or add a test.html file in the .well-known folder and try to access it through URL, then I’m redirected to hvalergjestehage.no (wrong virtual host) with a 404 not found.
for the default nginx server I added this location:
If I try accessing the url adminserver.rodningenmarketing.no/.well-known now, then I get 403 forbidden… Can that be why the test.html file was not found?
The problem is that is it is not NGINX that is responding it is the webmin server process! I made no confi changes at all to the APache webserver config. Simply a symbolic link from the webmin web root/.well-known to the Apache virtual domain root/.well-known.
Apologies I don’t have any experience as to how NGINX would treat following a symlink. Maybe the webmin admins could help.
Hi Joe, do you have any suggestions on how to get this letsencrypt acme-challenge working for the virtualmin host (adminserver.rodningemarketing.no)? The symlink and location on default server is active, but it doesn’t seem to find files/subfolders within the symlink/root when accessed through url.
What symlink are you talking about? I think this thread has become too chaotic for me to be useful. I literally have no idea what’s going on. There are normally no symlinks involved in the Let’s Encrypt validation process.
So I have a virtual host registered with rodningenmarketing.no… and I’m trying to get a SSL certificate for the virtualmin host on adminserver.rodningenmarketing.no. The validation fails.
The problem is that adminserver.rodningenmarketing.no seems to be redirected to the virtual host on hvalergjestehage.no (since it’s the first server in nginx list of servers). Therefore the LE validation process ends up looking for acme-challenge in hvalergjestehage.no/.well-known/acme-challenge/…
I’ve tried adding a custom location on the nginx “default server” (see my post above), which sets the correct root… also tried to add a symlink from /var/www/html/.well-known to /home/rodningenmarketing/public_html/.well-known
I added a test.html inside /home/rodningenmarketing/public_html/.well-known. This is accessed correctly on rodningenmarketing.no/.well-known/test.html, but getting 404 through adminserver.rodningenmarketing.no/.well-known/test.html. If I try to see adminserver.rodningenmarketing.no/.well-known I get a 403.
When you have a server with a domain name that is a sub-domain of a virtualmin virtual server then the letsencypt process fails as it appears to start ok with looking in .well-known under the virtual server but when it hits the sub-domain it then looks in the web root of the webmin/virtualmin server and not the virtual server that it is a part of.
It was looking in /var/html/.well-known which does not of course exist. I created a symlink to ourdomain.com public_html/.well-known and viola it could validate the subdomain and then issues the certificate.
That is why I stated that it was the webmin/virtualmin server that was answering for the sub-domain and not the virtual server apache server process.
I suspect this is only an issue when the webmin/virtualmin server is part of a virtual server domain.
Why isn’t this the problem we’re trying to solve? It sounds like the wrong site is being served. So, Let’s Encrypt shouldn’t even be in the conversation, right?
I’m not familiar enough with how nginx makes decisions about what to serve, but I assume there’s a problem with one of the virtual host configuration sections.
Stop with all the links. That’s just confusing.
Where is /var/www/html coming from? No Virtualmin host ever gets configured to point to /var/www/html. All domain websites live in subdirectories under /home. Is there a virtual host configuration section pointing to /var/www/html? Where did it come from?
I’m not sure if that’s the problem to solve. adminserver.rodningenmarketing.no isn’t supposed to be serving anything else than virtualmin on port 10000. I should note that it worked getting a LE-cert for this subdomain out of the box in February if I remember correctly…
back to the problem: I guess it should work again if nginx serves rodningenmarketing.no instead of hvalergjestehage.no OR if LE tries to do the acme-challenge in rodningenmarketing.no somehow. What do you think?
The nginx default-server has /var/www/html set as its root. So since I assumed it was the default-server which responded, I tried to make a symlink from here.
