which the Let's Encrypt certificate authority uses in order to confirm that the person who asked for a certificate from Let's Encrypt really controls the associated domain name. Let's Encrypt is trying to download a file from your site, after someone asked for a certificate for your site from Let's Encrypt, and the certificate requester was challenged to post the specified file with the specified contents.
The fact that these are all resulting in 404 Not Found errors shows that the challenges didn't succeed.
This could happen when you unsuccessfully try to get a Let's Encrypt certificate using software that expects to be able to make the requested site content change in order to prove your control over the domain name, but in fact fails to make the change. For example, that could happen if you used an application like Certbot but told it the wrong directory path to put challenge files in, so the challenge files never ended up in the expected place on your site.
It could also happen if someone else is maliciously trying to get a certificate for your site. (Fortunately, if so, it's not anywhere close to succeeding.)
It could also happen if someone else is mistakenly trying to get a certificate for your site. For instance, sometimes people on this forum have tried for days and days to get a certificate, only to discover that they had a typo in the domain name that they entered, and they didn't actually own the exact name that they had typed in. (Like .com instead of .net, or .co instead of .com, or forgetting a hyphen, or something.)
It could also happen if there's an old server that's still on the Internet that used to be responsible for serving your web site, but no longer is (because the DNS records have now been pointed to a different server). If the old server doesn't realize this, then its Let's Encrypt client software would repeatedly try to renew its old certificate, but futilely because the renewal will typically only succeed on the server that the DNS records are currently pointed to. So if you have obsolete infrastructure or something still running with an out-of-date configuration—including anywhere else in the world, like on a different cloud provider—it might mistakenly continue to request certificates for your site that it's not eligible to obtain.
It all sounds very reasonable apart from a couple of things:
This server is the FIRST server in my domain to have ANY SSL Certificate and its had SSL Certificates for the domain and two forums for well over a month.
I've been (unsuccesfully) trying to get a certificate for a dedicated mail server- A different server in the same domain with a different name and a different IP address.
I only put in a tiny sample of the 404s I have 2 or 3 PAGES of them and all with different IP addresses.
Well, there's most likely another server somewhere that's requesting these certificates automatically. It could be yours (somehow) or it could be someone else's.
I only have two server. The one I'm getting all the 404s from and the NEW one with just apache on it that I can't install a certificate on and I definitely haven't been trying 2 or more pages full of attempts
Or it could well be would-be hackers? Would it be possible to hack? Are hackers TRYING to hack it?
Nope, they'd be making much more interesting requests.
When you request a cert for something.yourdomain.com Let's Encrypt looks up which IP that points to then attempts the type of http request you see in your logs. If you have an IPv6 address for your host name then it will try that first.
If you can provide an example domain that currently can't get a cert perhaps we could help you debug that. It's worth checking your fully qualified hostnames with https://letsdebug.net
That's rather outside the scope of this Community I'm afraid
The reason why people might trigger ACME validations is maybe the initiator hopes that some sysops have their webserver configured in such a way, it'll respond with a valid ACME challenge response for even unsolicited ACME validation attempts. This would be obviously a VERY BAD THING and no webserver/ACME client should EVER respond to unsolicited ACME validation requests.. If the validation attempts are answered with the expected "404 file not found" or similar error, then there is no issue at all. Only if the webserver/ACME client would be horrendously stupidly configured it would be an issue. Which does not seem to be the case here. Nevermind that, it would be impossible unless the ACME accounts private key had been leaked, as the response includes the key authorization, which uses the account key.
An alternative answer would be that people accidentally have used your domain name. Maybe a typo or something. Not something to worry about.
I used the Let's Debug test site against your hermes and even corp domain names yesterday trying to debug your problem with hermes cert.
One part of that site's test is to make a cert request on Let's Encrypt staging system. The request will fail of course since it cannot place the required challenge token on your server. But, it can identify comms problems or other server config issues.
The most common result, and the expected one, is 404 errors. Each test may result in as many as 4 http requests to your server. Let's Encrypt servers try these from varying IP addresses around the world.
My own tests won't explain the Sep1 or later Sep3 log entries but perhaps other volunteers tried Let's Debug as well when reviewing your previous problems.
You should see many of these on your hermes server log too. I continue to think requests to hermes are not getting to that server. You could try running Let's Debug test yourself and see if they show up in hermes access log.
I think there's a problem somewhere with the actual server. We tried to install phpbb on it and we couldn't install it. Tried Joomla, same problem
started over. Different datastore (new disk) using 58 instead of 61, because CentOS 7 had been working on that IP for years. I changed the local IP from 206 to 216.
I installed PHP 7.4 and opened all the Ports I have on my other server.
