[amluto]

The one thing that I find bizarre about this: why did Cloudflare feel inspired to special-case /.well-known/acme-challenge at all? The only thing I can think of is that clients were having caching issues (Cloudflare caching the challenge value, clients forgetting to set cache-control headers, and challenges therefore failing), but that seems like a bit of a weak reason to special-case anything. Anyone using Cloudflare should already know how to set cache control headers.

[Dylan16807]

My guess would be that aggressive blocking was causing verification to fail, since it gets verified from multiple well-separated locations.

[amluto]

If a user’s verification attempts fails because their own rules block access, that doesn’t sound like a Cloudflare bug. If a user’s verification attempt fails because of Cloudflare’s built in rules, maybe that’s an issue, and maybe Cloudflare tried to fix that and messed up.

All that being said, this workflow is rather odd. We’re talking about a customer who uses an HTTP-01 challenge to get a certificate for a domain that is proxied by Cloudflare’s TLS-terminating proxy. Setting this up in a way that is useful is dramatically harder than letting Cloudflare deal with the certificate. Maybe the idea is that the user could example proxying and get something vaguely secure without any reconfiguration at all all on the origin machine? How many users have ACME configured and are willing to run a wide-open origin behind Cloudflare anyway?