Detail: 64.135.63.5: Invalid response from (clipped) 404

I have used letsencrypt quite a lot over the last several years without an issue. For this client however, I have the problem listed below. I'm not at all familiar with the internals of cerbot so I am quite at a loss as to the problem/solution. I have opened the firewall for the ip address for 80 and 443. I have successfully run a dry run for another website, iotguide.com (redirects to internetofthingsguide) and internetofthingsguide, both on the same server which uses sperate ip addresses. My sense is that it might have something to do with other websites (on this server) sharing the same ip address with amusementsguide.com. Is that likely? All the websites work on port 80 and the configurations are <Virtualhost *:80>....

Any help is appreciated.

My domain is:amusementsguide.com

I ran this command:certbot certonly --dry-run --apache -d amusementsguide.com -v

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache
Simulating a certificate request for amusementsguide.com
Performing the following challenges:
http-01 challenge for amusementsguide.com
Waiting for verification...
Challenge failed for domain amusementsguide.com
http-01 challenge for amusementsguide.com

Certbot failed to authenticate some domains (authenticator: apache). The Certificate Authority reported these problems:
Domain: amusementsguide.com
Type: unauthorized
Detail: 64.135.63.5: Invalid response from http://amusementsguide.com/.well-known/acme-challenge/2V1Zhvm3g972_vW0A971VSha33pKRx5rYdn62TPmKD0: 404

Hint: The Certificate Authority failed to verify the temporary Apache configuration changes made by Certbot. Ensure that the listed domains point to this Apache server and that it is accessible from the internet.

Cleaning up challenges
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):
Server version: Apache/2.4.18 (Ubuntu)
Server built: 2016-04-15T18:00:57

The operating system my web server runs on is (include version):
Ubuntu 16.04 (i know, this is a client)
My hosting provider, if applicable, is: self/colocation

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

1 Like

Well, possibly related to a mix of VirtualHosts but probably not in the way you are imagining. Unless you've mixed IP and Name based VHosts which can get very messy.

My first guess is you have multiple VirtualHosts for that same domain name. Second is to check the spelling of the ServerName in its VHost. Could you have spelled it amusementguide instead? :slight_smile:

A good place to start is showing us output of this:

sudo apache2ctl -t -D DUMP_VHOSTS
2 Likes

Thank you,
The dump output is attached as vhost-dump.txt and the breakdown of domain/ip is ip-breakdown.txt
Not using ip based virtual hosts but name <VirtualHost *.80>

vhost-dump.txt (8.6 KB)
ip-breakdown.txt (1.7 KB)
Thanks again,
Robert

1 Like

Yes, but my understanding is that you can't share ips using ip based virtual host. Am I mistaken?

Thank you,
Robert

1 Like

That is correct for IP based VHosts. But, some people mistakenly setup more than one name-based VirtualHost with the identical set of ServerName and ServerAlias names and the same port (like 80).

Apache allows this even though only one of the VHosts will be selected to process incoming requests based on SNI

Certbot will update one of them when using --apache plugin but it may not be the one selected by Apache via SNI. Thus leading to a 404.

Now that I see your VHost dump you have not made that mistake.

EDIT. Will need a minute to eval and need to step away for a bit

2 Likes

Supplemental information Port 443 is CLOSED.

$ nmap -Pn -p80,443 amusementsguide.com
Starting Nmap 7.80 ( https://nmap.org ) at 2024-04-27 21:09 UTC
Nmap scan report for amusementsguide.com (64.135.63.5)
Host is up (0.089s latency).
rDNS record for 64.135.63.5: ip.portfolio.metroguide.com

PORT    STATE  SERVICE
80/tcp  open   http
443/tcp closed https

Nmap done: 1 IP address (1 host up) scanned in 0.41 seconds
2 Likes

I see where I screwed up. Can't fix it until later tonight/tomorrow. I am migrating host of an haproxy machine and left the ip active so its going to another machine (smh)....
Anyway, I'll update once I get this sorted out.

Thanks!!
Robert

3 Likes

The output shows:

port 80 namevhost amusementsguide.com (/etc/apache2/sites-enabled/amusementsguide.com.conf:2)
            alias amusementsguide.com
        alias www.amusementsguide.com

Which has two things I find out-of-place:

  • there is an alias to the same exact name:
    namevhost amusementsguide.com
    alias amusementsguide.com

  • it includes "www" but the cert requests doesn't:
    alias www.amusementsguide.com
    certbot certonly --dry-run --apache -d amusementsguide.com -v

5 Likes

this was the problem. i overlooked this lol....

Thank you!
Robert

4 Likes