Certbot failed to authenticate some domains (authenticator: webroot)

Help
1

Hi,

I have tried applying new certbot certificate for a gitlab container.

I have gitlab container running in a AWS ubuntu 18.04 instance. I am accessing Gitlab through Public IP of that instance.

The gitlab container is mapped to port 80,443 of the EC2 instance.

I am not using Ngnix or Apache.

Help me in finding out the webroot plugin for it.

Below is the error which appeared.

2021-09-17 09:50:24,367:DEBUG:certbot._internal.display.obj:Notifying user:
Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
Domain: xxxx.com
Type: unauthorized
Detail: Invalid response from http://xxxx.com/users/sign_in [x.x.x.x]: "\n<html class="devise-layout-html">\n<head prefix="og: http://ogp.me/ns#">\n<meta charset="utf-8">\n<meta content="IE"

Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.

1 Like
2

@Ramprasad Welcome.

You have not provided much info but I will point out one thing. Your container is redirecting the challenge request coming from the Lets Encrypt servers to a sign-in page of yours. You should be responding with the contents of a file placed in your container by Certbot. When you use Certbot, it talks to the LE servers which in turn make requests to prove you control the domain. Those requests look something like

http://(domain)/.well-known/acme-challenge/l4ufCi7IRQUr0dWquVWuL6S7y2EW14sdJjujfWB6QBY

If that is not enough to resolve your problem, please complete the form you were provided for Help topics:

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command:

It produced this output:

My web server is (include version):

The operating system my web server runs on is (include version):

My hosting provider, if applicable, is:

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

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

The version of my client is (e.g. output of `certbot --version` or `certbot-auto --version` if you're using Certbot):
4 Likes
3

Are you using any web service?
[please answer all the questions posted above (by @MikeMcQ)]

If not using a webserver, then how can you expect webroot to work?
Maybe try using --standalone instead.
[hard to say for sure - since you haven't answered the questions yet]

3 Likes
4

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: http://tanzu.gvsmb.com

I ran this command:
sudo certbot certonly --webroot --agree-tos --email ramprasad.venugopal@example.com -d tanzu.gvsmb.com -w /.well-known/acme-challenge/

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for tanzu.gvsmb.com

Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
Domain: tanzu.gvsmb.com
Type: unauthorized
Detail: Invalid response from Sign in · GitLab : "\n<html class="devise-layout-html">\n<head prefix="og: http://ogp.me/ns#">\n<meta charset="utf-8">\n<meta content="IE"

Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.

Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

My web server is (include version): I have an Ubuntu EC2 instance with a public IP and have launched a Gitlab container in it. I have opened port 80,443 of the gitlab container so that Gitlab is accessible through the port 80 of the public IP of instance. I have mapped the public ip to the DNS as tanzu.gvsmb.com. Now I have to apply ssl certificate to the DNS. I have installed certbot and there is some issue applying SSL certificate.

The operating system my web server runs on is (include version): Ubuntu 18.04.5 LTS

My hosting provider, if applicable, is: gvmsb.com

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): No

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

6

The ordering in your certbot command is incorrect.
The --webroot and -w parts must come before the domain they are to be applied to.

Try:

sudo certbot certonly \
--webroot  -w /.well-known/acme-challenge/ \
-d tanzu.gvsmb.com 
--agree-tos \
--email ramprasad.venugopal@example.com
4 Likes
7

Sorry in further review:

That may be a relative path and an absolute path is expected.

Further-furthermore...
The --webroot used should match the DocumentRoot (or Root) used by the web service for that FQDN (or at least for where the expected challenge path would be served from).

In other-other words, the --webroot should indicate where to find the .well-known folder (not where to find the challenge file itself).

4 Likes
8

It's actually an absolute path, but probably very incorrect. As it would suggest someone has the absolute root of their filesystem as the webroot of their website.. Which is highly unlikely.

3 Likes
9

@Osiris Agreed; it seems to be relative to the request, but incorrectly detailed in an absolute format [which won't match the webserver's search for the file, nor likely even exist - as you pointed out (root paths are hardly ever used and should never be shared between tenants or web services)]

10

Hi,

I have launched a Gitlab container in a EC2 instance. The Gitlab container contains Ngnix running inside it.

My question is that should the certbot needs to be installed inside the container? The port 80,443 of container has been opened and mapped to instance.

11

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