LetsEncrypt Renewal Failing with CloudFlare enabled IPv6 --> IPv4

Greetings! I was banging my head trying to figure out why Lets Encrypt renew was failing. I was able to serve the ACME auth if I hit the URL in my browser. But Lets Encrypt would fail with a Type: unauthorized.
As soon as I disabled Cloud Flare the renew worked.

We only have IPv4 enabled – no IPv6 support.

I noticed that the ACME bot was accessing the URL using IPv6 which would go to CloudFlare. But given I don’t have IPv6 DNS in CloudFlare my assumption is it would route to IPv4 through the CloudFlare reverse proxy.

As I type this I realize maybe this is more of a question for Cloud Flare but I do want to post here to see if anyone else has experienced this and/or those smarter than I could provide any insight.


IPv6 shouldn’t matter here. Let’s Encrypt will access your site over IPv6 if you use Cloudflare, but Cloudflare will proxy the request to your origin server over IPv4 if you give them an IPv4 address.

It’s strange that you’re having issues with Cloudflare enabled. I’ve done this many times without issue - on one of my company’s domains we use a LE cert for communication between Cloudflare and our origin server. (And just like you, our origin only supports IPv4)

Could you share your domain so we can see if there’s some config issue?


Thanks @BenSjoberg I re-enabled CloudFlare and did a dry run - which now successfully works :man_shrugging: - I guess I’m going to chalk it up to some overly aggressive caching?? one of our sysadmins suggested “so while the request comes over ipv4, x-forwarded-for value is an ipv6 address, so nginx internally thinks it came over ipv6” - but given it’s working now seems caching is most likely explanation. Though strange because each tokenized acme url would be unique. Domain is superuser.openstack.org

1 Like

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