Virtualmin the Website Encountered an Unexpected Error. Please Try Again Later.
#1 Thu, 08/02/2018 - 03:32
[SOLVED] Error when installing SSL Document with Let's Encrypt
Hi, I'one thousand having the post-obit problem: when I try to install a SSL Certificate via Let's Encrypt I get the following error:
mywebsite.com claiming did not pass: Invalid response from http://mywebsite.com/.well-known/top-claiming/dliVUxI70M8nAmgaUduK0cCi7PSxOq-plNq5nAl0W4E: "<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><trunk>
<h1>Non Found</h1>
<p"
I have two virtual servers installed, does information technology for both sites. One already has an SSL certificate but when I endeavour to get a new document for it (just like the other ane) I get this error. If I remember correctly, I installed the SSL certificate when PHP script execution mode was still gear up to Apachemod_php, however I subsequently set up information technology to FCGId.
I have tried to manually create a ".well-known/top-challenge/" folder and placed and empty file inside - I can download information technology no problem.
Can anybody requite me a clue how to ready this?
EDIT:
SOLUTION
What solved the problem for me was installing certbot through the command line, following this tutorial (note it's a Digital Ocean tutorial, but I'k on OVH, then it should be completely host agnostic). "sudo certbot" and choosing the sites I want to install certificate to did the job and that was literally information technology. Information technology was shockingly piece of cake for a CLI operation :).
Virtualmin the Website Encountered an Unexpected Error. Please Try Again Later.
Source: https://archive.virtualmin.com/node/58287
#2 Fri, 08/03/2018 - 18:23
Kvark
check chmod settings on public_html its non able to create binder and file for elevation-challenge try chmod -R ugo+rw public_html
Pitiful, for the belatedly answer - was away for a few days. Unfortunately, nothing changed. I fifty-fifty tried setting everything to 777, just to test it out, merely the problem persisted.
Joe
Never set permissions to 777. If the owner:group is right, and information technology is grouping readable (and grouping x all the fashion up the path, then Apache can see the directories), your permissions are fine.
Only, this is definitely non a permissions trouble. Permissions problem would exist a 403 Forbidden mistake. 404 indicates something is making the path inaccessible in the configuration.
#5 Midweek, 08/22/2018 - eleven:57
My certificates accept been renewing properly over the final yr but my latest i is displaying the same fault as yours. The challenges are being written to the acme-challenge directory and I tin access the directory without difficulty. Non sure why the change unless some update has caused a problem.
#6 Wed, 08/22/2018 - 20:38
Joe
Your PHP execution mode has no relation to this error.
You probably have a redirect or proxy dominion happening that prevents access to the well-known directory. If you've got some sort of web app that sucks up all requests check your .htaccess file. You lot probably need to exclude redirecting or proxying the .well-known directory.
Y'all can check this past only trying to load that URL in your browser. You demand to sort out why it's a 404...it's gotta exist web server configuration, if the file exists.
#7 Wed, 08/22/2018 - 22:56
I have had this trouble in the by...ive unfortunately forgotten what the cause was.
Are you running nginx? Is it configured to use the same directory as lets encrypt?
https://community.letsencrypt.org/t/404-error-at-well-known-acme-challenge/44271/6These posts may exist of help as it appears to throw same mistake as yours...
https://customs.letsencrypt.org/t/unauthorized-404-error-well-known-meridian-claiming-on-a-hosting-web-infinite/55512/4https://customs.letsencrypt.org/t/404-for-well-known-acme-challenge/38381
https://ajecreative.com.au
#eight Fri, 08/24/2018 - 21:xix
Freddy63
You're not using Cloudflare are you?
#ix Saturday, 09/01/2018 - 17:34
I have the same problem: I tin can not install a new certificate with Let's Encrypt.
I receive the same error:
Failed dominance procedure. www.reformascarlos.es (http-01): urn:acme:fault:unauthorized :: The customer lacks sufficient say-so :: Invalid response from http://world wide web.reformascarlos.es/.well-known/acme-challenge/hcEx3gC0a5TocAD4cnVOWD0qRMuPaub-RxUbDja_Zv8: "<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML ii.0//EN"><html><head>
<title>404 Non Constitute</title>
</head><torso>
<h1>Not Plant</h1>
<p", reformascarlos.es (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authority :: Invalid response from http://reformascarlos.es/.well-known/acme-claiming/YjVWcCyk65qr6QZHHFUKiuxwXCsE0sndBxv-P3fkHd0: "<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Non Establish</title>
</head><body>
<h1>Not Institute</h1>
I tin can non access to the new virtual server http://reformascarlos.es, I get some other virtual server previously configurated.
When I access to https://reformascarlos.es, information technology works fine
Any idea?
Can anybody give me a inkling how to fix this?
Thanks
#10 Sun, 09/02/2018 - xvi:49
I answer myself.
This page is the solution:
https://world wide web.virtualmin.com/documentation/web/troubleshooting#toc-the-wro....
Information technology was a trouble of misconfiguration of virtual server:
grep -i '<virtualhost' /etc/apache2/sites-enabled/*.conf
/etc/apache2/sites-enabled/reformascarlos.es.conf:VirtualHost *:80
/etc/apache2/sites-enabled/reformascarlos.es.conf: VirtualHost v.189.142.150:443
#11 Sun, 09/02/2018 - sixteen:52
#12 Mon, 09/03/2018 - 02:21
fran: Thanks for the tip, just sadly this is not the trouble in my case. The output seems to indicate everything is fine in that regard:
stanoam@vps548154:~$ grep -i '<virtualhost' /etc/apache2/sites-enabled/*.conf/etc/apache2/sites-enabled/cosmeticmachines.com.conf:<VirtualHost 54.38.214.126: 80 [2001:41d0:801:2000::23]:80>
/etc/apache2/sites-enabled/cosmeticmachines.com.conf:<VirtualHost 54.38.214.126: 443 [2001:41d0:801:2000::23]:443>
/etc/apache2/sites-enabled/dentalshopsupplies.com.conf:<VirtualHost 54.38.214.12 6:80 [2001:41d0:801:2000::23]:lxxx>
/etc/apache2/sites-enabled/dentalshopsupplies.com.conf:<VirtualHost 54.38.214.12 6:443 [2001:41d0:801:2000::23]:443>
Freddy63: No, it'due south an OVH VPS.
Freddy63
I see your DNS is properly configured and y'all have an active certificate for ane domain which is expiring in 8 days.
I may exist able to help you fix this. You can contact using link in the signature if y'all're interested.
#14 Wednesday, 09/05/2018 - 22:20
I finally figured out my problem after another of my domains updated successfully. Somehow I had managed to modify the ownsership of the peak-claiming directory of the problem account to root instead of the domain owner. After setting information technology back the renewal updated as expected.
#fifteen Thu, 09/06/2018 - 02:49
Hey, everybody. I think I finally solved the problem. I just installed certbot, had information technology set the certificate and... it just worked. Information technology shows that my SSL Certificate will expire on December 5th, rather than September 11th, equally it was. Honestly, I'll just leave it at that for the moment and be content with information technology only working. I solar day, when I accept more than time, I might actually investigate what the problem was, but for now I'yard simply happy to have a valid certificate :). Thanks to everybody for the suggestions. Cheers.
#sixteen Sat, 01/05/2019 - 07:53
Kvark
In addition - just encounter same effect - virtual host with Drupal 7 on it, was not able to laissez passer acme chalange, afterward investigation I institute out that information technology was considering of .htaccess file (and so maybe if you take like effect even if not using Drupal, cheque that)
When creating certificates using LetsEncrypt a folder called ".well-known" is created in the websites public folder (which is typically Drupal's root folder). The line RewriteRule "(^|/)." - [F] in Drupal'southward default .htaccess file specifically prohibits files and folders starting with dots being accessed. This causes LetsEncrypt to fail when issuing certificates and provide mistake letters about authorisation (403 Forbiden).
To ready that is needed to replace this line in .htaccess:
RewriteRule "(^|/)." - [F]byRewriteRule "(^|/).(?!well-known)" - [F]This allows admission to the .well_known folder but denies all other dot-paths. Later on that fix certificate has been updated without whatever issues.
Joe, perhas it volition exist worth to add together check in script to see if its a .htaccess restriction in identify to create summit-challenge folder?
#17 Friday, 01/xi/2019 - 04:59
I'm not trying to hijack the thread, but I'm commenting in instance people come up here because of the same trouble in the future, in case information technology helps.
I also had the same problem as you lot guys, a letsencrypt unable to properly renew itself.
In my instance, the only gear up that worked was to basically delete every certificate-related file at the root of this virtualhost's storage directory, ssl.ca, ssl.cert, ssl.combined, ssl.everything, ssl.key. One time the files were deleted (fill-in first!), virtualmin finally managed to properly set letsencrypt.
Kvark
that perhaps permisions on that files was not right, but yes, skillful to add together only in example.
#19 Sat, 03/02/2019 - 06:40
eugenevdm.host
We had a similar problem on one of our servers which seemed a bit odd because we host many Drupal seven sites. What stood out and what different nearly this server is the the domain proper noun, and there dwelling house directory and username, and a "." (dot) in it. It was something like ourdomain.co.whatever. Then so nosotros renamed the domain to something temporary, similar ourdomain1.co.whatever, and then we renamed information technology back. Only when renaming information technology dorsum nosotros made sure that the three sections, namely:
did not have a "." (dot) in anymore. Non really certain if the rename also perhaps fixed some unknown permissions event. But all adept now, even with the original .HTACCESS the site is renewing.
Eugene van der Merwe
https://vander.host WordPress Website Hosting, VPS Hosting, and Domain Registration
#xx Wednesday, 04/03/2019 - 00:25
Web and Mobile Application solution provider company Locus Rags
#21 Mon, 04/15/2019 - 03:eighteen
I'yard leaving this here in case someone else made the simple fault I did. I striking the letsencrypt limit and temporarily used a redirect from http to world wide web. I accept a multisite and without valid SSL, subdomains route to the main site.
Then I forgot virtually it.
In my case, the redirect was why letsencrypt couldn't verify my domain (yes, I felt stupid)
#22 Mon, 04/xv/2019 - 09:39
Since this thread is becoming THE reference for letsencrypt renewal bug thread with virtualmin on google, I'll mention two other cases I had on the dedi on which I host websites for a off-white number of friends or relatives.
First case, already documented hither, an .htaccess that wasn't assuasive to access something located within a ./well-known/something/stuff/whatever subdirectory starting with a dot. Honestly no idea what office of the .htacess wasn't allowing it, all I know is that temporarily removing the htacess (renaming) immune letsencrypt to practise its stuff. Still, worth an email to the owner of the website, he'll have to get his .htaccess stock-still within the next three months.
Second case, Apache unable to restart, which prevented the reloading of the configuration files required for the conclusion of a letsencrypt renewal. That was a problem unrelated to letsencrypt, the kind of oddball bug that may happen in very random circumstances ( https://world wide web.virtualmin.com/node/64984 ). Only whatever, in other people's cases, keep in listen Apache may be running perfectly well, merely might still be unable to exist reloaded. So, just in instance, try a service apache2 restart, and if information technology doesn't wing (don't worry, the system checks offset if apache would manage to restart, if it can't, it doesn't allow apache to close down at all), you have an caption.
#23 Thu, 04/25/2019 - ten:57
I solved this by disabling configserver and then performing the update or request and everything appears to work normally. I would like to know how to configure Configserver so I don't accept to disable it at all
#24 Mon, 09/16/2019 - 11:15
I went through all mentioned solutions here even so, when I manually created .well-known and .well-known/height-challenge folders (with possessor of domain permissions), then it was able to request cert. My agreement that it is non able to create those folders and hence not able to create verification file in it.
#25 Thu, 11/14/2019 - 05:45
For me, it was a trouble with the nginx configuration for the site, afterwards I changed it for Wordpress / url rewriting. Solution was to add together a location match for .well-known/.
See this answer here: https://stackoverflow.com/a/58854557/1451903
Edit: apologies, I thought the original issue was a 403, not a 404. My answer relates to a 403 fault.