@Stegan - out of curiosity: what are the ownership\permissions for the well-known directory? I’d expect it to be domain_owner:domain_owner and 0755.
JoeVirtualmin Staff
What is the full error?
Requesting a certificate for *****.com, www.*****.com from Let's Encrypt ..
.. request failed : Web-based validation failed :
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for *****.com and www.*****.com
Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
Domain: www.*****.com
Type: unauthorized
Detail: 2600:3c03::f03c:93ff:fe42:f3f3: Invalid response from http://www.*****.com/.well-known/acme-challenge/nya38M6KjXskUicDMjY5Ytbt-czr0IxcotXem8Z9MkY: 404
Domain: *****.com
Type: unauthorized
Detail: 2600:3c03::f03c:93ff:fe42:f3f3: Invalid response from http://*****.com/.well-known/acme-challenge/wZjlJ6X69GtvxZXeoSyBdSoqSxQm41eMFenok6NfN0I: 404
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.
DNS-based validation failed :
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for *****.com and www.*****.com
Certbot failed to authenticate some domains (authenticator: manual). The Certificate Authority reported these problems:
Domain: *****.com
Type: dns
Detail: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.*****.com - check that a DNS record exists for this domain
Domain: www.*****.com
Type: dns
Detail: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.www.*****.com - check that a DNS record exists for this domain
Hint: The Certificate Authority failed to verify the DNS TXT records created by the --manual-auth-hook. Ensure that this hook is functioning correctly and that it waits a sufficient duration of time for DNS propagation. Refer to "certbot --help manual" and the Certbot User Guide.
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.
Access: (0755/drwxr-xr-x) Uid: ( 1002:domain_owner) Gid: ( 1002:domain_owner)
I’ve had a couple similar issues with Ubuntu 22.04 and nginx. I’ll post them here in case you’re having the same problem.
My issue was Nginx not booted with system.
I found 2 reasons for this,
-
Nginx doesn’t start with OS - Sometimes nginx just isn’t configured to start on a reboot. So everything will work fine until you reboot the server, then your websites stop working and so does Let’s Encrypt.
Just run systemctl --now enable nginx and request the certificate again. -
Nginx failed to start with OS - Nginx fails to boot up with can’t allocate IP address error. The IP address though is always a IPV6 address. I’m not sure the exact reason. But it may be that nginx booting before the network is fully up.
Just run systemctl start nginx after a reboot.
Hope these help
Do you mean to be using IPv6? Are you sure your AAAA record points to the right place? A 404 makes me think Let’s Encrypt is hitting the wrong server.
If you do intend to use IPv6 for this domain, does Virtualmin know you intend to be using IPv6? If it hasn’t created IPv6 configuration on the right IP for this domain, you’d also probably get a 404, even if the record is correct and pointing to the right IP.
If you do intend to use IPv6, and you do have the right IP in those records, and you do have Virtualmin setup to configure IPv6 in your web server, we next need to see the access and error log entries for this domain when you try to validate the domain. That’ll presumably tell us why it’s serving a 404 (or nothing will show up, which means either DNS or webserver configuration is wrong, despite your beliefs about the above questions).
Ultimately - Yes.
This is a new box (see @Dibs suggestion above) on Linode (a provider I am not familiar with) on creating the box they implemented the A and AAAA records and performing an external check seems to show their IP (location NY) for the box. So I assume the records are correct.
I then loaded Virtualmin in the usual way as a LEMP build (no changes from the default settings) The default “Website Enabled” page then is displayed in a browser. (So I must assume that because I can find that page so should LE be able to find it!)
I have looked in the nginx access/error logs for today (after running another failed LE request (this time just for the domain.email not www.domain.email) and there are no strange 404 errors. So LE must be looking elsewhere? There are only a few 404 errors seem to be from random browsing
Though there is a letsencrypt.log generated:
2022-11-13 10:18:31,983:DEBUG:certbot.error_handler:Calling registered functions
2022-11-13 10:18:31,983:INFO:certbot.auth_handler:Cleaning up challenges
2022-11-13 10:18:31,984:INFO:certbot.hooks:Running manual-cleanup-hook command: /etc/webmin/webmin/letsencrypt-cleanup.pl
2022-11-13 10:18:33,672:DEBUG:certbot.log:Exiting abnormally:
Traceback (most recent call last):
File "/bin/letsencrypt", line 11, in <module>
load_entry_point('certbot==0.40.0', 'console_scripts', 'certbot')()
File "/usr/lib/python3/dist-packages/certbot/main.py", line 1382, in main
return config.func(config, plugins)
File "/usr/lib/python3/dist-packages/certbot/main.py", line 1265, in certonly
lineage = _get_and_save_cert(le_client, config, domains, certname, lineage)
File "/usr/lib/python3/dist-packages/certbot/main.py", line 121, in _get_and_save_cert
lineage = le_client.obtain_and_enroll_certificate(domains, certname)
File "/usr/lib/python3/dist-packages/certbot/client.py", line 417, in obtain_and_enroll_certificate
cert, chain, key, _ = self.obtain_certificate(domains)
File "/usr/lib/python3/dist-packages/certbot/client.py", line 348, in obtain_certificate
orderr = self._get_order_and_authorizations(csr.data, self.config.allow_subset_of_names)
File "/usr/lib/python3/dist-packages/certbot/client.py", line 396, in _get_order_and_authorizations
authzr = self.auth_handler.handle_authorizations(orderr, best_effort)
File "/usr/lib/python3/dist-packages/certbot/auth_handler.py", line 91, in handle_authorizations
self._poll_authorizations(authzrs, max_retries, best_effort)
File "/usr/lib/python3/dist-packages/certbot/auth_handler.py", line 180, in _poll_authorizations
raise errors.AuthorizationError('Some challenges have failed.')
certbot.errors.AuthorizationError: Some challenges have failed.
I am starting to agree with that opinion.
I have been monitoring one DNS Checker - DNS Check Propagation Tool on and off for the past hour or so and every now and then the number of “resolved” changes with an incorrect IP4 poping up. Does LE only enquire of only one DNS resolver? Perhaps that is why LE is failing to find the correct A record? Do browsers have a more general lookup and accept any that resolve correctly.
Your browser will be using whatever DNS servers your ISP has (i.e. what your internet connection is using) or others, if you have set them to Google’s or others in your router config.
LE will be using whatever it has at it’s server level.
Unlikely to be the same.
1 Like
If any DNS server that is considered authoritative for your domain is serving the wrong IP, you need to fix it. How would Let’s Encrypt or any other client on the internet know which one is the right one, if it gets multiple answers and one is wrong?
For me that just suggests all the problems lie with LE with them not being able to resolve my A record even though every one else seems to be able.
Taking a closer look at the nginx access log I’m being hit by folk all over the place from China, Ukraine, Russia to the US. some with odd requests most of which get a 404 (eg .env robots.txt etc) all the normal guff
But how? I am not responsible for these. or for which the DNS Checker or LE choose to use.
Again I have checked this utility this morning and a few (4) of them seem to flip flop between the correct IP4 and some other IP4 (I think it might be the old box - before I took it over at DO) The one that concerns me most is the one geographically near the Linode box “Holtsville NY, United States” (Open DNS) who I would have thought to be pretty reliable. It is now well over 48hrs!
@Stegan - In your shoes, I’d be sorely tempted to redo the Linode box as a LAMP stack, purely to discount whether there is an issue in your “build\install” process or the issue lies outside your box.
On a side note - I don’t think you should need to create the well-known directory.
@Stegan - In your shoes, I’d be sorely tempted to redo the Linode box as a LAMP stack, purely to discount whether there is an issue in your “build\install” process or the issue lies outside your box.
That is scary! It must be 20+ years since I last had anything to do with Apache.
Does Linode enable rebuilding from an image as DO does? I don’t want to lose this IP by destroying the box and starting yet another.
should it be there? Because it is not. (it is a fresh install on the Linode box)
does LE or Virtualmin create it (should it) or should I as I did above for that test page?
I believe you can rebuild from an image without loosing the IP. The IP only goes back into the “pool” if you actually delete the VPS.
As for the directory - I’ve never had to create one. I could be wrong but I wouldn’t expect it to be there initially (assuming SSL is not enabled). So there would be no reason to create it.
If you then enable SSL - stuff should work out of the box, i.e. Virtualmin\LE should create it.
I would test the self-signed cert 1st (albeit with Chrome “errors”) and once the self-signed SSL works, try for a LE one. Without creating any directories yourself.
1 Like
No, it didn’t.
I have also checked on a fully functioning Virtualmin (with a LE cert) back on a DO box: and neither does that one. So I assume it is left up to certbot to create + use + destroy the .well-known dir
Yes - I’d go with that theory.
1 Like
You are responsible for your glue records, which determine what DNS servers are authoritative for your zones (configured at your registrar). And you’re responsible for the NS records within your zone. If any of those points to a server that provides incorrect data, which seemingly has to be the case based on your description of the problem, Let’s Encrypt will potentially fail and requests from clients will potentially fail.
1 Like
After some input from Gandi it turns out that these had somehow been set and once they helped by deleting them (I had no idea or knowledge of them) the external searches for the A records settled down.
and FINALLY this morning LE supplied a cert
I also transferred a new domain as a virtual server and LE immediately added SSL
Faith restored 
This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.