The ssl certificate that has the mail domain mail.dimpro.com.co and mail.dptc.com.co we need to renew it, the attempt to make it automatic by means of the manual or the manual is generating an error.
What command are you executing that results in the output you posted? The output indicates that your web server is returning an html page when Let’s Encrypt requests the challenge file instead of the proper response.
You should try creating a test text file in the acme-challenge directory and see if you can load that in a browser properly. I’m suspecting some configuration on your web server is redirecting those requests.
Good afternoon Jaredm,
The command that is being used is the following:
letsencrypt-auto-renew
The SSL certificate is for a mail server, He was renewing automatically, but now that he has only 20 days he does not want to do it and the mentioned error comes out.
I also do not find the path you mention acme-challenge
If you look at the contents of the file /etc/letsencrypt/renewal/mail.dinpro.com.co.conf, it will say what method is used to authenticate (to prove your control over the domain name). The error that you receive is happening when the certificate authority tries to verify that the person requesting the new certificate (you) is really the same person who controls the domain name.
Probably this file will mention authenticator = webroot, which refers to a method of proving control of the domain name by creating a file at a specified location on the web site. In this case, there should also be a line that says webroot_path = and some directory location on your system. This was chosen when the certificate was originally issued, and then remembered by the Certbot software by saving it in this file.
You should confirm that the directory indicated is really a directory where web content can be placed in order to appear at the top level of your web site.
The acme-challenge directory that @jared.m referred to is a detail of the validation process which I guess you’re not familiar with, which is that the certificate authority will request your machine to create a file with a specific, random name within /.well-known/acme-challenge on your site. Normally this happens automatically as part of the renew command, but if your web configuration has changed in some way, possibly Certbot might not be able to create a file in the appropriate location.
So for example, you might have a line in the configuration file that says something like webroot_path = /var/www/html. In that case, @jared.m is suggesting that you should create a file like
By the way, Certbot is the new name of the software that you’re running as letsencrypt-auto (for more than a year now). It will still work to use the command letsencrypt-auto, but we now call this software Certbot.
Sí, pero no es muy probable que /etc/letsencrypt sea la webroot correcta, porque el servidor no obtendrá los contenidos de allí. No sé como /etc/letsencrypt se hizó su webroot.
Normally you just need to specify the location where web content for your web site is served from. You don’t need to add the /.well-known/acme-challenge because Certbot will add that for you automatically.
The procedure is done to create the file and it is displayed without problem by browser, the path where our website is / etc / letsencrypt / webroot
But the error continues.
How did you choose /etc/letsencrypt/webroot as your webroot? Surely the rest of your website isn’t served from there? Did you add something referring to this path in your web server configuration file?
Something that’s interesting to me is that I can see the presence both of an nginx server and of an Apache server. I guess that the nginx server is acting as a reverse proxy for the Apache server?
When I saw the Bad Gateway error, it was from nginx
If I try to access a nonexistent file in this directory, I get a 404 error from Apache
If I access the files successfully, they’re served by nginx
When you attempted to get the certificate using Certbot and received an error, it looks like the error was returned by nginx
Is it possible that the /.well-known/acme-challenge is mapped specially by the nginx reverse proxy and that the main site, including other paths, is served by Apache?
We did the tests that you did not indicate and worked, but did not give the renewal, and we gave the permissions to the hidden paths and edited the .confi by placing the complete path (/ etc / letsencrypt / webroot) and the result of the renewal was successful.
