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: sistema.qualitte.com.br
I ran this command: docker-compose up
It produced this output: certbot_1 | Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
certbot_1 | Domain: sistema.qualitte.com.br
certbot_1 | Type: unauthorized
certbot_1 | Detail: Invalid response from https://sistema.qualitte.com.br/.well-known/acme-challenge/rEU2mMApeKPCKP5AYmi0Paw0wDsqGYslDoy4DlGrgAk [168.196.132.211]: "<meta http-equiv=X-UA-Compatible content="IE=edge,chrome=1"><meta name=renderer c"
certbot_1 |
certbot_1 | 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.
certbot_1 |
certbot_1 | Saving debug log to /var/log/letsencrypt/letsencrypt.log
certbot_1 | Some challenges have failed.
certbot_1 | 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):
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): yes
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):
When you use the webroot authentication option in certbot, you must specify the path of the webroot directory by either using a parameter (-w or --webroot-path) or entering the path while certbot is running. If the incorrect path is specified, certbot will create the challenge directories and files in the wrong place, resulting in the Let's Encrypt server being unable to find them.
You would probably benefit from using the nginx authenticator (--nginx) rather than the webroot authenticator (--webroot) to avoid having to specify the correct webroot path and/or handle certain challenges of proxying in nginx.
When you ran Certbot the request came to your server and was redirected from http to https. That is ok but not needed for Lets Encrypt requests.
Your redirect had the LE server make another request but with https. Your server responds with what looks like a script page for login. It should respond with the special file placed there by Certbot.
You could upload your nginx conf but I think if you add this to your port 80 server it will work
location /.well-known/acme-challenge/ {
root /var/www/certbot; # path used for certbot -w
}
@leison But then it is not working because you can see in your first post the request is for https. That only happens when your server redirects from http to https
I think @Osiris's comment may hold sway here. If nginx and certbot are operating in separate containers, no amount of messing with nginx itself will do anything alone.
Very true, one needs to be sure the locarion where certbot puts the challenge file is also accessible from inside the nginx container. That requires fiddling with the volumes of both Docker containers.
Yes. Access to either files or ports need to be correlated between the two containers, and the host. IMHO, this is easiest to do with a proxypass; it looks like the link you shared implements a proxypass solution though I didn't read it well.
