Looking at what you’ve posted, whatever is hitting your server is not Boulder/Let’s Encrypt validation traffic. Others in this thread (@webprofusion, @Nummer378, @JamesLE, @MikeMcQ, @PeterCooperJr, etc.) have already laid out the main reasons:
The requests don’t use /.well-known/acme-challenge/...
The methods and paths (HEAD/GET/POST on / and /_next) don’t match any ACME flow
The User-Agent string is trivially spoofable
On top of that, the IPv6 address you posted (2a0f:85c1:356:2f48::1) is announced by a generic VPS provider (AS215659, Aokigahara SRL / “MOEMOEKYUN” / Kyun), not by Let’s Encrypt/ISRG. So, between the path pattern and the whois/ASN data, we can say confidently: these are just generic scans spoofing a Let’s Encrypt-like UA, not real LE validation.
The bigger problem, though, is that everyone here is forced to guess because key details are missing:
We don’t know the domain name
We don’t know your CAA records
We don’t know your DNS-01 vs HTTP-01 configuration
We don’t know what ACME client(s) you’re actually using on this host
All of those are essential if you want a definitive answer, especially around CAA and challenge method policy. Without the domain, nobody can:
Check CAA (including any accounturi restrictions or allowed methods)
Correlate timing with real issuance attempts (via crt.sh, etc.)
Verify whether LE would even be allowed to attempt HTTP-01 for your domain
Right now, the only thing we can say with certainty is:
These requests are not coming from Let’s Encrypt.
They look like ordinary VPS-based recon traffic with a forged UA.
To go further than that, we need the domain and basic DNS/CAA context.
If you’re willing to share the domain (or at least your CAA configuration and which challenge types you intend to allow), people here can give you a much more precise and useful answer. Otherwise, the safest conclusion is simply: block or ignore these requests; they’re not part of any legitimate Let’s Encrypt validation.
I certainly would have no problem posting details, but my aim is not to address my specific issue, but rather to be the "canary in the coal mine" for anyone else seeing similar traffic. I was hoping to shed extra light on links/tools/etc. that can be used to audit LE's operations, even by people who don't use LE, but who might find their way here after seeing similar entries in their logs.
To my thinking, the bigger picture problem is that things like this happen at all. I mean, there isn't anything special about my server setup that would make this a direct attack of some kind. So why is anyone constructing these very specific spoofed requests? One possibility that comes to mind is an ACME client exposing some exploitable info at that path.
If nothing like that is clicking in the head of anyone yet, there's really nothing more to do at this time. Here's hoping a connection is made before some vulnerable target sites get hacked.
/_next is used by next.js which was affected by CVE-2025-55182, I'm not aware of any ACME clients using next.js however a vulnerable server could be used to get a certificate.
I think they are looking for servers that are badly configured and allow extra access for requests with a Let's Encrypt user agent. In essence using the user-agent as a password.
Thank you for your feedback. We'll take it under consideration, though changing how validation works is definitely not an easy task. My colleague has already confirmed this is not a request from us.
To everyone else, this is reasonable feedback. Please don't feel the need to argue with every point somebody brings up.
I found the same entries in the web server log. The first entry was at
[09/Dec/2025:22:25:57 +0100] the last one at [11/Dec/2025:21:12:32 +0100],
all originated from the IP 176.65.148.66
You can get some info from reverse dns, but I don't know how you'd possibly authenticate it and I assume that's only going to tell you about HA1 and HA2, not the multiperspective/secondary validation system.
Publicly trusted certificates are published on certificate transparancy logs, which are also publicly accessible. This is a well known vector for bots and other malicious actors to harvest hostnames from in hopes to e.g. find freshly installed webapps with default passwords to hijack. Or vulnerabilities.
To the extent it matters, I can answer "no" to all of them. My setup is very customized, and I don't even use a public-facing server to request my certs (for Cloudflare reasons).
Those addresses happen to be in networks that were added to my firewall due to ongoing abuse (the first going all the way back to Oct 2022!). That's the reason I'm guessing my hits were via IPv6.
Those look awful to me, which probably means they'll be approved, given the state of the web these days. New headers and more "well-known" probing? Ugh. For audit purposes, all that is needed is a nonce added to the URL that most bots already put in the user agent.
The crawler used user-agent "Mozilla/5.0 (compatible; Lets Encrypt validation server; +https://www.letsencrypt.org)".
Of course, the user-agent could be spoofed. So, I asked ChatGPT about the IP 65.87.7.112, since, for some reason, Let's Encrypt doesn't publish a list of the IP addresses it uses for validation.
Yes, it definitely was. User-agent strings can be set to whatever you wish.
You can make a curl request yourself with that same user agent string. There is nothing exclusive about it to anyone.
Up to you. You will only receive HTTP challenge requests from Let's Encrypt when you actually make a certificate request using the HTTP Challenge method. If you see requests at other times it is not from LE.
See this FAQ answer and the page it links to for more info: FAQ - Let's Encrypt
From what I understand, the short answer is: "The IP address 65.87.7.112 does not belong to Let's Encrypt."
If that's the case, I will block that IP immediately on our servers.
I only posted the question here because the accesses occurred exactly at the time we renewed our certificates, and we don't have a tool to confirm if the IP belongs to Let's Encrypt.
There is no epistemological basis for anything LLMs generate. It's all hallucinations. I would encourage you to stop using and passing along AI slop.
Well, the /19 it's in has been in my firewall since September for being abusive, as are many other ranges with the same owner (IPXO). But I also happen to block legitimate LE servers/services due to them being on cloud providers that are the source of attacks, too; decide for yourself what kind of attack surface you're willing to expose.
It's still a bit of a mystery why this particular spoof is happening.
