Allow LetsEncrypt through Firewall Rules

In my CloudFlare account I have, and
I’ve restricted access for using some special cookie. If that cookie isn’t present, then it will block the request.

  1. fw-allow-dev: ( eq "" and http.cookie contains "is-dev=my-secret-cookie"), action: Allow
  2. fw-block-dev: ( eq ""), action: Block

So if they have the cookie, they will be allowed to access the Development Website, if they don’t then they’ll see Error 1020. This is expected, but now the problem is, LetsEncrypt doesn’t have the cookie, and when they go request the ACME Challenge, it gets blocked.
What should I do to let Lets Encrypt access the folder so it can verify the domain?
I can’t add this to rule fw-allow-dev: or (http.request.full_uri contains "") because then if I go to it contains the string, so it will allow it. Is there anything I can do to check with like regex? I think something like this ^https?:\/\/dev\.example\.com\/\.well-known\/acme-challenge\/ could work, but I’m not sure I’m able to do that with CloudFlare Firewall.

What should I do about this?

You could try eq "" and (http.cookie contains "is-dev=my-secret-cookie" or http.request.uri.path eq "/.well-known/acme-challenge/")

You could also try to only have one block rule and negate your expression.

1 Like


( eq "" and not http.cookie contains "is-dev=my-secret-cookie" and http.request.uri.path ne "/.well-known/acme-challenge/")
1 Like

From what I could see in the blocked logs the request is something like:


I’m not sure if that “file” will always have the same name, or if it’s randomized every time it tries to renew.

In this case, just switch from Letsencrypt webroot domain validation to using DNS validation. Most popular Letencrypt clients do support using DNS validation. I use client and you can easily do this using client’s supported DNS API’s which support Cloudflare DNS API.


You could use contains here too, though that would still allow for the issue you mentioned.

The easiest thing might be to simply allow the IP address (block) or ASN of Lets Encrypt.

Let’s Encrypt deliberately do not publish such a list, so ASN or IP rules cannot be created for the validation requests.

Well, requests will still come only from a certain set of addresses or blocks, so one can narrow down that. They might change but it might be easier than changing the whole approach. Alternatively, there’s only the DNS validation left.

A Business plan, which does support such a regular expression, is of course an option too.

They moved to multi-point validation some time ago, and they have stated that they will essentially randomise the request source IPs. Is as common a question on their community forum as Flexible is here, and the response is always the same. DNS-01 is the best option where the hostname is not public.


That I got :wink:. But they won’t randomise among a /0, there will be a handful of networks where these requests come from.

That requires mentioned change in approach.

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