I'm not quite sure what you are saying either. Are you saying you must block all incoming requests for /.well-known/acme-challenge because you get such a large number of fake requests?
And, how large of a volume of fake requests are there? Normally an HTTP request is redirected to HTTPS and you could block anything you want there (port 443). Just be sure to handle the acme-challenge request directly in the HTTP VirtualHost. You would get fake HTTP requests still but simply redirect them same as fake requests to your "home" page or any other. That shouldn't be much of a burden on your server.
Depending on your Certbot options this may already be happening for legitimate cert requests. We'd have to know the contents of your renewal config in /etc/letsencrypt/renewal
UPDATE:
Another option that might help is to switch to using the mod_md feature in Apache to get your certs rather than Certbot. It supports the TLS-ALPN challenge (on port 443) so you could block whatever you like on port 80. See:
We check every 404/301 to see if the request could make sense. For example, we don't have WordPress in any vHost, so all IPs searching for WordPress can be blocked.
There are also *.php requests in the “/.well-known/acme-challenge/” directory that can be blocked.
Because many vHosts use the same server, this greatly reduces the number of “meaningless” false requests.
I would prefer to block all IPs with requests in “/.well-known/*” with status code 404.
I'm not concerned which server is serving the challenges for validation. I'm concerned which server is requesting the challenges be validated (ie running the ACME client). I think it's fully possible for admins to have a concept of their outbound IP addresses (or ranges). It's not perfect, but a client running from Beijing clearly won't have a Toledo IP address, barring some deliberate VPN action. This type of suggestion isn't authentication-level. It's simply an 80/20 or better way of filtering junk traffic. Obviously layering, proxying, and NATting makes such an approach difficult. Just wishful thinking.
I suppose account-based authentication handles this more succinctly per what @petercooperjr mentioned earlier with the CAA record.
Over the years I've often worried about rogue clients being used to robot-command the LE servers to essentially perform DOS attacks (or something perceivable as DOS attacks).
From 5M accounts: "Here, validate this domain, 20M times."
The current certificate is fresh and from IP X, and if IP Y fails several times, this should be taken into account, right?
25/10/10 domain.tld new cert IP X
25/10/11 domain.tld fail renew IP Y
25/10/12 domain.tld fail renew IP Y
...
26/01/10 domain.tld fail renew IP Y
26/01/10 domain.tld new cert IP X
26/01/11 domain.tld fail renew IP Y => X queried correctly twice, incorrectly over 60 times during that period
P.S. Or is there also a client ID or something similar?
Then Let's Encrypt should count the error requests per domain and reset the client ID to zero if this client is validated correctly.
If a second client can validate multiple times without any problems, the error client will be denied validation.
This should be feasible, but it will also consume a lot of data.
P.S. The ratio of ErrorClient to PerfectClient is at least 60:1 per period.
I think it will be a bit more nuanced than that, but yes, that's generally along the lines of what I was thinking. It's essentially binding a "client authentication" to a DNS zone (or section thereof).
Essentially:
This client (via account) can request certs for this domain name, now prove that you are that client (via account) by signing a nonce or such.
In addition to the scenarios above, it is also important to remember that a domain can change owners, servers, and even clients/accounts from one day to the next.
A DNS record for Let's Encrypt? Various other services do this too.
Of course, this makes things more complicated again
P.S. However, a DNS record would not really be useful, as the domain is managed externally by the customer.
Only the current controller (or a delegate thereof) of the DNS zone for any given domain name should be able to acquire certificates for said domain name. The account binding is the delegation.
Until recently, this customer only had one subdomain for our service and the domain was managed by another provider. This meant that two different clients from different LE accounts were responsible for the domain and subdomain respectively!
P.S.
And that is precisely the problem now: the old client tries and it doesn't work, and the new/current one receives the certificate and the failed requests from the old client.
Yep, unfortunately there's not much you can do about this. They're running a client, requesting certificates for a domain they no longer control. We'll eventually pause them (preventing them from requesting any more certs for that domain, and stopping the validation attempts that are hitting your server), but as mentioned above we're pretty conservative about how quickly we engage that pausing mechanism.
We can't bind domains to accounts -- there are many organizations that run a separate ACME client on each of their load balancers, so each of those different clients is successfully requesting certs for the same set of domain names.
Your best bet is to reach out to this customer's previous hosting provider and ask them to fix their ACME system. They shouldn't be requesting certs for names they no longer control; that's just a waste of everybody's resources.
