Http-01 challenge fail

I've read all of the other HTTP-01 challenge fail threads and cannot, for the life of me, figure out why I cannot fix this. I am unable to use snapd or repl to install certbot package and therefore I am using docker container.

This is the final step before taking my website live. Any help would be greatly appreciated :slight_smile:

My domain is: qvntra.io

I ran this command:
sudo docker run -it --rm --name certbot
-v "/etc/letsencrypt:/etc/letsencrypt"
-v "/var/lib/letsencrypt:/var/lib/letsencrypt"
certbot/certbot certonly

It produced this output:
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 1
Plugins selected: Authenticator standalone, Installer None
Please enter in your domain name(s) (comma and/or space separated) (Enter 'c'
to cancel): qvntra.io, www.qvntra.io
Requesting a certificate for qvntra.io and www.qvntra.io
Performing the following challenges:
http-01 challenge for qvntra.io
http-01 challenge for www.qvntra.io
Waiting for verification...
Challenge failed for domain qvntra.io
Challenge failed for domain www.qvntra.io
http-01 challenge for qvntra.io
http-01 challenge for www.qvntra.io
Cleaning up challenges
Some challenges have failed.

IMPORTANT NOTES:

My web server is (include version): Apache/2.4.46

The operating system my web server runs on is (include version): Amazon Linux AMI 2018.03

My hosting provider, if applicable, is: AWS

I can login to a root shell on my machine (yes or no, or I don't know): Yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): Wordpress + phpMyAdmin

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot/latest (docker container)

I notice a few things:

  • you're using the standalone plugin, which spins up a temporary webserver on port 80 with aid of a certain Python webserver module. This temporary webserver won't reply anything else but the validation token. So if the request is wrong, it won't output anything and if the request is correct, it'll output the validation token, which is just a hexadecimal string, nothing more.
  • The response the Let's Encrypt validation server gets when it tries to query the validation token contains HTML. Probably produced by your Apache webserver, most certainly not produced by the standalone plugin I mentioned above.

So a few questions:

  • On which server do you run your certbot Docker instance?
  • Does that Docker container even receive the validation requests on port 80?

Because as I see the situation now, you're running Apache on port 80, probably without the use of Docker and a certbot Docker instance also running a webserver on "port 80" (the standalone plugin), but entirely within that Docker instance.

A few things might work, such as stopping your Apache, mapping the servers port 80 to your certbot Docker port 80, running certbot again with the standalone plugin, get the certificate, start Apache again.

However, I would suggest to use the webroot plugin. You should map your Apaches webroot to a location in your Docker instance with that -v option (I have no clue how Docker works...) and use the webroot plugin in certbot with the -w option pointing to that webroot location in your Docker container.

1 Like

I feel stupid. This solved my problem.

sudo service httpd stop

sudo docker run -it --rm -p 80:80 --name certbot
-v "/etc/letsencrypt:/etc/letsencrypt"
-v "/var/lib/letsencrypt:/var/lib/letsencrypt"
certbot/certbot certonly

sudo service httpd start

Thank you very much <3

2 Likes

I would urge you to look into the webroot plugin method. That wouldn't require stopping your Apache! While the standalone plugin with stopping and starting Apache could be automated too (not sure how that would work from within Docker tho), the webroot plugin can be automated more easily. Although that would still require reloading your Apache from within the Docker container..

Remember you need to renew your certificate every 60 days (it's valid for 90 days and Let's Encrypt recommends you keep a 30 days window for disaster control, so it recommends to renew after 60 days already).

1 Like

Can you help me understand how the webroot method would be stood up with Apache? I was unsuccessful in getting this to work. When it asked for a directory, I got:

/var/www/html/.well-known/acme-challenge/ does not exist or is not a directory
/var/www/html/.well-known/acme-challenge does not exist or is not a directory
/.well-known/acme-challenge does not exist or is not a directory

Any advice on how to get this working with Apache and a WordPress instance that wants to handle everything would be greatly appreciated. It would be nice to set and forget auto-renew with certbot.

Note that I don't have experience with Docker. Also, could you post the exact non-working command you've tried which resulted in those errors?

In general lines it would come down to:

  • Identify the webroot path used by Apache, i.e., the option for the DocumentRoot directive from the Apache configuration
  • Map that directory to a directory inside Docker using that -v option for Docker
  • Enter that mapped webroot directory inside your Docker container in certbot, either when asked for it by certbot or with the -w option.
  • Don't include the /.well-known/acme-challenge/ part to the webroot path you enter into certbot: certbot will add it for you.

I am going to switch to webroot in 60 days. I understand now. The only thing that is not clear to me is what volume to map to "???:/var/www/html" in docker. The rest of it makes complete sense.

??? is the location on your server outside Docker, right? Well, that depends on the DocumentRoot setting in your Apache configuration. Could be /var/www/html too, but can also be something else entirely.

Sorry, after reading Use volumes | Docker Documentation it seems it's the other way around.

Well, in that case, it could be anything you want. But could also be /var/www/html I assume. Just use that directory for the webroot-path in certbot.

For example:

sudo docker run -it --rm --name certbot
-v "/etc/letsencrypt:/etc/letsencrypt"
-v "/var/lib/letsencrypt:/var/lib/letsencrypt"
-v "/path/to/somewhere:/var/www/html"
certbot/certbot certonly --webroot -w /path/to/somewhere
2 Likes
??? = directory in Docker container.

I would be mapping that to my DocumentRoot. I don't know how the container functions, but I'm guessing it would generate my .pems in ??? and then I would want to map my DocumentRoot (/var/www/html).

I will read through how to use the container better soon.

The .pem files (i.e., certificates and private keys) are stored in /etc/letsencrypt.

sudo docker run -it --rm --name certbot -v "/etc/letsencrypt:/var/www/html" -v "/var/lib/letsencrypt:/var/lib/letsencrypt" certbot/certbot certonly --webroot -w /var/www/html


Challenge failed for domain qvntra.io
Challenge failed for domain www.qvntra.io
http-01 challenge for qvntra.io
http-01 challenge for www.qvntra.io
Cleaning up challenges
Some challenges have failed.

IMPORTANT NOTES = The following errors were reported by the server:

Domain: qvntra.io
Type:   unauthorized
Detail: Invalid response from
http://qvntra.io/.well-known/acme-challenge/5e29bV8X3d2IzzvRwF-r3MaIqOO9prlJ_NbKEIixdmE
[3.95.23.31]: "<!DOCTYPE html>\n<html
lang=\"en-US\">\n<head>\n\t<meta charset=\"UTF-8\">\n\t<link
rel=\"profile\" href=\"https://gmpg.org/xfn/11\">\n\t<title>"

Domain: www.qvntra.io
Type:   unauthorized
Detail: Invalid response from
http://www.qvntra.io/.well-known/acme- 
challenge/EsTNUAN_Q_3CiHrv9M2FZ3eVdZK5065c3AltXEU6VAs
[3.95.23.31]: "<!DOCTYPE html>\n<html
lang=\"en-US\">\n<head>\n\t<meta charset=\"UTF-8\">\n\t<link
rel=\"profile\" href=\"https://gmpg.org/xfn/11\">\n\t<title>"

To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address.

It's fighting with my Apache Webserver + WordPress again.

This is an odd one? Previously, you mapped /etc/letsencrypt to /etc/letsencrypt, which is good. Now you've made it into your webroot?

Perhaps you misunderstood me earlier: I said the .pem files are stored in /etc/letsencrypt. The .pem files are NOT the files you want in your webroot! You want the extensionless, temporarily generated token file in your webroot, which is totally different from .pem files.

This probably would work:

sudo docker run -it --rm --name certbot
-v "/etc/letsencrypt:/etc/letsencrypt"
-v "/var/www/html:/var/www/html"
-v "/var/lib/letsencrypt:/var/lib/letsencrypt"
certbot/certbot certonly --webroot -w /var/www/html --staging --cert-name test-certificate

I've added --staging and --cert-name test-certificate so you can test the command out without bothering the production server and risk running into rate limits.

If the above command is succesful, you might want to issue a "real" (i.e., non-staging i.e. non-fake) certificate by running the same command without --staging and --cert-name test-certificate, overwriting your previous certificate (which would increase the load a very tiny little bit on the Let's Encrypt services) or you can do that 60 days in the future when it's time to renew.

The benefit of doing it now is that you can test if certbot renew works by running certbot renew --dry-run. You might have forgotten or lost your notes in the upcoming 60 days :wink:

1 Like

This works. Just ran it with success. I am going to setup renew now. Thank you very much for the time!!!

2 Likes

Probably a wee bit off-topic, but how would I go about fixing this issue? I've got the certificate for both qvntra.io & www.qvntra.io domain names, but whenever Google Domains forwards to my server's public IP address, it resolves as my server's Public IPv4 DNS and conflicts with the certificates I just generated.

Is this something I can fix in my Apache WebServer?

Sounds more like a Google Domains issue to me?

By the way, I can't connect to your site at all:

osiris@erazer ~ $ curl -LIv qvntra.io
*   Trying 3.95.23.31:80...
* connect to 3.95.23.31 port 80 failed: Connection timed out
* Failed to connect to qvntra.io port 80: Connection timed out
* Closing connection 0
curl: (28) Failed to connect to qvntra.io port 80: Connection timed out
osiris@erazer ~ $ curl -LIv www.qvntra.io
*   Trying 3.95.23.31:80...
* connect to 3.95.23.31 port 80 failed: Connection timed out
* Failed to connect to www.qvntra.io port 80: Connection timed out
* Closing connection 0
curl: (28) Failed to connect to www.qvntra.io port 80: Connection timed out
osiris@erazer ~ $ 

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.