Certbot failed to authenticate some domains (authenticator: webroot) Invalid response from http://www.site.com/.well-known/acme-challenge/... 404

Help
1

Hello, everyone. First I installed Letsencrypt through sudo certbot certonly --apache, but afterwards got to know, that it is not for CDN (Cloudflare sites), so I deleted carefully certificates by this instruction and deleted certbot itself by this manual. Installed everything again with command “sudo certbot --authenticator webroot --installer apache” and got “Certbot failed to authenticate some domains (authenticator: webroot) Invalid response from 404”

I have 3 Virtualhost sites with site.com and www.site.com names, I pointed during installation. The sites ape placed to /var/www/site.com/public_html paths, that I point as a webroot directory (every path to it’s site).

My domain is: https://homeproxy.pro

I ran this command: sudo certbot certonly --webroot --agree-tos --email mail@gmail.com -w /var/www/site.pro/public_html/ -d site.pro -d www. site.pro -w /var/www/site.com/public_html/ -d site.com -d www.site.com -w /var/www/site.org/public_html/ -d site.org -d www.site.org

It produced this output: Certbot failed to authenticate some domains (authenticator: webroot) Invalid response from http://www.site.com/.well-known/acme-challenge/... 404

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

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

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 2.7.0.

Sites directory public_html is missed somehow during challenge. It produces site.com/.well-known instead of site.com/public_html/.well-known, though it t is pointed in conditions. I tried to create .well-known/acme-challenge 755 folders in site.com directory (without public_html), also, changed domain .conf to DocumentRoot /var/www/site.com, but helplessly. Before certbot reinstall, there was “failed to authenticate” only, without 404.

Additional info:

  • Sites configs are under <VirtualHost *:443>
  • Cloudflare SSL Full (strict) mode is now off
  • Apachectl configtest is OK
  • Ports 80,443 in ufw are opened
  • Both A-records on Cloudflare point to the correct hosting server IP
  • .htaccesseS are temporary renamed
2

Those are two completely different domains.
Please only show the actual domain name(s) you own/operate.

1 Like
3

**site**.pro.com.org is only for illustrative purpose. My domain is homeproxy.pro, sorry for the mess.

4

Have you considered just using the Cloudflare Origin CA Cert on your origin server? This is a one-time process to get a cert. It is only valid for use when your domain name is proxied at Cloudflare so that you are using its CDN. But, if it suits your needs it would probably be easier.

2 Likes
5

I thought Origin Certificates encrypt only traffic between Cloudflare and my origin server, not traffic from client browsers to my origin server. It is pointed on Cloudflare page ( Troubleshooting)

6

I'm puzzled by the whole getting a certificate, deleting everything and doing the same thing all over again-part of your post.

That's entirely correct, but with Cloudflare proxying enabled, client browsers won't connect to your origin server, but to Cloudflare.

1 Like
7

I am too a little bit, but sudo certbot certonly --apache command does not support CDN.

This means I cat use Cloudflare Origin cert if my traffic proxied and customers will visit site by https?

8

Correct. But clients usually connect to Cloudflare CDN Edge. The CDN makes another connection to your origin server. But yes if you have clients bypassing that and connecting directly to your origin you would need your own certificate.

But, if you have set up a different domain name that is not proxied so that they can connect directly to your origin, then there wouldn't be a reason for you to adjust the cloud flare strict settings either. That only applies when you are using the CDN.

1 Like
9

It doesn't have to.
The CDN should be transparent.

1 Like
10

But that would be highly unlikely. Those clients would somehow manually use your origin servers IP address and, if SNI is required, couple that to your hostname e.g. using the hosts file or custom DNS. Not likely.

11

Not planing to switch off CDN, so, Cloudflare origin cert can be way out, thanks. By the way, each site needs own cert installed?

12

That was explanation for Osiris, what I started re-installation from the very beginning for.

13

Correct. To bypass the CDN means to setup another domain name that is not proxied to allow direct connection. You cannot use a CF Orign CA cert for that connection.

2 Likes
14

But that wouldn't be an issue with SNI, as the domain name would be different.

It should be no problem combining proxied and non-proxied hostnames.

15

It would not be a problem with sni. Who said it was? Some experienced admins like the option of temporarily disabling the CDN so of course the origin cert would not work for that instance either.

2 Likes
16

If the CF origin cert would be configured as default cert, any client without SNI would always get the CF origin cert. That, in theory, could lead to issues, although I'm not familiar with non-SNI TLS clients though.

Besides the theoretically SNI/non-SNI issue, there is no problem combining a CF origin cert with a regular cert for a different domain.

17

Cloudflare CDN does not support non-sni clients in their free plan. But, yes, if you need to support non-sni clients special considerations need to be taken.

2 Likes
18

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