[SOLVED] Error when installing SSL Certificate with Let's Encrypt

25 posts / 0 new
Last post
#1 Thu, 08/02/2018 - 03:32
mao_dze_dun

[SOLVED] Error when installing SSL Certificate with Let's Encrypt

Hello, I'm having the following problem: when I try to install a SSL Certificate via Let's Encrypt I get the following error:

mywebsite.com challenge did not pass: Invalid response from http://mywebsite.com/.well-known/acme-challenge/dliVUxI70M8nAmgaUduK0cCi7PSxOq-plNq5nAl0W4E: "<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p"

I have two virtual servers installed, does it for both sites. One already has an SSL certificate but when I try to get a new certificate for it (just like the other one) I get this error. If I remember correctly, I installed the SSL certificate when PHP script execution mode was still set to Apachemod_php, however I subsequently set it to FCGId.

I have tried to manually create a ".well-known/acme-challenge/" folder and placed and empty file inside - I can download it no problem.

Can anybody give me a clue how to fix 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'm on OVH, so 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 it. It was shockingly easy for a CLI operation :).

Fri, 08/03/2018 - 18:23
Kvark
Kvark's picture

check chmod settings on public_html its not able to create folder and file for acme-challenge try chmod -R ugo+rw public_html

Fri, 08/10/2018 - 14:46 (Reply to #2)
mao_dze_dun

Sorry, for the late reply - was away for a few days. Unfortunately, nothing changed. I even tried setting everything to 777, just to test it out, but the problem persisted.

Wed, 08/22/2018 - 20:41 (Reply to #3)
Joe
Joe's picture

Never set permissions to 777. If the owner:group is correct, and it is group readable (and group x all the way up the path, so Apache can see the directories), your permissions are fine.

But, this is definitely not a permissions problem. Permissions problem would be a 403 Forbidden error. 404 indicates something is making the path inaccessible in the configuration.

--

Check out the forum guidelines!

Wed, 08/22/2018 - 11:57
ksihota

My certificates have been renewing properly over the last year but my latest one is displaying the same error as yours. The challenges are being written to the acme-challenge directory and I can access the directory without difficulty. Not sure why the change unless some update has caused a problem.

  • Operating system CentOS Linux 7.5.1804
  • Webmin version 1.890
  • Usermin version 1.741
  • Virtualmin version 6.03
  • Theme version Authentic Theme 19.19
  • Firewall version ConfigServer Security & Firewall 12.06
Wed, 08/22/2018 - 20:38
Joe
Joe's picture

Your PHP execution mode has no relation to this error.

You probably have a redirect or proxy rule 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 probably need to exclude redirecting or proxying the .well-known directory.

You can check this by simply trying to load that URL in your browser. You need to sort out why it's a 404...it's gotta be web server configuration, if the file exists.

--

Check out the forum guidelines!

Wed, 08/22/2018 - 22:56
adamjedgar

I have had this problem in the past...ive unfortunately forgotten what the cause was.

  1. i would check to ensure your webserver permissions to the directory in question are correct
  2. Has the directory outlined in the error above actually been created? If not then that may help in the problem solving process.
  3. This may be a result of my inexperience, but can i throw it out there anyway...i note the URL in the error is http ...shouldnt it be putting the challenge in https?
  4. Have you opened port 443 for https? (once again i dont know what error this throws in terms of the acme challenge passing)
  5. 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/6

  6. These posts may be of help as it appears to throw same error as yours...

https://community.letsencrypt.org/t/unauthorized-404-error-well-known-acme-challenge-on-a-hosting-web-space/55512/4

https://community.letsencrypt.org/t/404-for-well-known-acme-challenge/38381

AJECreative is the home of $5 webhosting, $15/month VPS servers (1cpu,1gb RAM, 25GB storage)
Centos7, Debian9, or Ubuntu18LTS
Available Control Panels = Centos-Webpanel, Cyberpanel, or Virtualmin

https://ajecreative.com.au

Fri, 08/24/2018 - 21:19
Freddy63
Freddy63's picture
Sat, 09/01/2018 - 17:34
fran

I have the same problem: I can not install a new certificate with Let's Encrypt.
I receive the same error:

Failed authorization procedure. www.reformascarlos.es (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.reformascarlos.es/.well-known/acme-challenge/hcEx3gC0a5TocAD4cnVOWD0qRMuPaub-RxUbDja_Zv8: "<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p", reformascarlos.es (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://reformascarlos.es/.well-known/acme-challenge/YjVWcCyk65qr6QZHHFUKiuxwXCsE0sndBxv-P3fkHd0: "<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>

I can not access to the new virtual server http://reformascarlos.es, I get another virtual server previously configurated.
When I access to https://reformascarlos.es, it works fine
Any idea?
Can anybody give me a clue how to fix this?
Thanks

Sun, 09/02/2018 - 16:49
fran

I answer myself.

This page is the solution:
https://www.virtualmin.com/documentation/web/troubleshooting#toc-the-wro....

It was a problem 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 5.189.142.150:443

Sun, 09/02/2018 - 16:52
fran

I think this page can help you:
https://www.virtualmin.com/documentation/web/troubleshooting#toc-the-wro...

I think is a problem of misconfiguration of virtual server.

Regards, fran

Mon, 09/03/2018 - 02:21
mao_dze_dun

fran: Thank you for the tip, but sadly this is not the problem 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]:80>
/etc/apache2/sites-enabled/dentalshopsupplies.com.conf:<VirtualHost 54.38.214.12                                                                           6:443 [2001:41d0:801:2000::23]:443>



Freddy63: No, it's an OVH VPS.

Mon, 09/03/2018 - 02:38 (Reply to #12)
Freddy63
Freddy63's picture

I see your DNS is properly configured and you have an active certificate for one domain which is expiring in 8 days.

I may be able to help you fix this. You can contact using link in the signature if you're interested.

Wed, 09/05/2018 - 22:20
ksihota

I finally figured out my problem after another of my domains updated successfully. Somehow I had managed to change the ownsership of the acme-challenge directory of the problem account to root instead of the domain owner. After setting it back the renewal updated as expected.

Thu, 09/06/2018 - 02:49
mao_dze_dun

Hey, everybody. I think I finally solved the problem. I just installed certbot, had it set the certificate and... it just worked. It shows that my SSL Certificate will expire on December 5th, rather than September 11th, as it was. Honestly, I'll just leave it at that for the moment and be content with it just working. One day, when I have more time, I might actually investigate what the problem was, but for now I'm just happy to have a valid certificate :). Thanks to everybody for the suggestions. Cheers.

Sat, 01/05/2019 - 07:53
Kvark
Kvark's picture

In addition - just meet same issue - virtual host with Drupal 7 on it, was not able to pass acme chalange, after investigation I found out that it was because of .htaccess file (so perhaps if you have similar issue even if not using Drupal, check 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's default .htaccess file specifically prohibits files and folders starting with dots being accessed. This causes LetsEncrypt to fail when issuing certificates and provide error messages about authorisation (403 Forbiden).

To fix that is needed to replace this line in .htaccess: RewriteRule "(^|/)." - [F] by RewriteRule "(^|/).(?!well-known)" - [F]

This allows access to the .well_known folder but denies all other dot-paths. After that fix certificate has been updated without any issues.

Joe, perhas it will be worth to add check in script to see if its a .htaccess restriction in place to create acme-challenge folder?

Fri, 01/11/2019 - 04:59
OliverF

I'm not trying to hijack the thread, but I'm commenting in case people come here because of the same problem in the future, in case it helps.

I also had the same problem as you guys, a letsencrypt unable to properly renew itself.

In my case, the only fix 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. Once the files were deleted (backup first!), virtualmin finally managed to properly set up letsencrypt.

Fri, 01/11/2019 - 10:48 (Reply to #17)
Kvark
Kvark's picture

that perhaps permisions on that files was not right, but yes, good to add just in case.

Sat, 03/02/2019 - 06:40
eugenevdm.host
eugenevdm.host's picture

We had a similar problem on one of our servers which seemed a bit odd because we host many Drupal 7 sites. What stood out and what different about this server is the the domain name, and there home directory and username, and a "." (dot) in it. It was something like ourdomain.co.whatever. So then we renamed the domain to something temporary, like ourdomain1.co.whatever, and then we renamed it back. But when renaming it back we made sure that the three sections, namely:

  1. Administration username
  2. Home directory
  3. User name suffix and group

did not have a "." (dot) in anymore. Not really sure if the rename also maybe fixed some unknown permissions issue. But all good 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

Wed, 04/03/2019 - 00:25
CharlieWilson

Web and Mobile Application solution provider company Locus Rags

Best Web and Mobile Application solution provider company[url=http://www.alertfreejob.com/business/locus-rags/] Locus Rags[/url]

Mon, 04/15/2019 - 03:18
manchego

I'm leaving this here in case someone else made the simple mistake I did. I hit the letsencrypt limit and temporarily used a redirect from http to www. I have a multisite and without valid SSL, subdomains route to the main site.

Then I forgot about it.

In my case, the redirect was why letsencrypt couldn't verify my domain (yes, I felt stupid)

Mon, 04/15/2019 - 09:39
OliverF

Since this thread is becoming THE reference for letsencrypt renewal problems thread with virtualmin on google, I'll mention two other cases I had on the dedi on which I host websites for a fair number of friends or relatives.

First case, already documented here, an .htaccess that wasn't allowing to access something located within a ./well-known/something/stuff/whatever subdirectory starting with a dot. Honestly no idea what part of the .htacess wasn't allowing it, all I know is that temporarily removing the htacess (renaming) allowed letsencrypt to do its stuff. Still, worth an email to the owner of the website, he'll have to get his .htaccess fixed within the next 3 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://www.virtualmin.com/node/64984 ). But whatever, in other people's cases, keep in mind Apache may be running perfectly well, but might still be unable to be reloaded. So, just in case, try a service apache2 restart, and if it doesn't fly (don't worry, the system checks first if apache would manage to restart, if it can't, it doesn't allow apache to shut down at all), you have an explanation.

Thu, 04/25/2019 - 10:57
snorkpants

I solved this by disabling configserver 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 have to disable it at all

Mon, 09/16/2019 - 11:15
Saahib

I went through all mentioned solutions here however, when I manually created .well-known and .well-known/acme-challenge folders (with owner of domain permissions), then it was able to request cert. My understanding that it is not able to create those folders and hence not able to create verification file in it.

Thu, 11/14/2019 - 05:45
serverwithoutsoul

For me, it was a problem with the nginx configuration for the site, after I changed it for Wordpress / url rewriting. Solution was to add 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 error.