CODEWITHSUNDEEP
terraformcloudflareacme
Brian Horakh
Brian Horakh

Reputation: 617

Terraform Cloudflare ListZonesContext command failed: Invalid request headers (6003)

As far as I know this was a working config that spontaneously broke recently. It appears Cloudflare may have changed the header validation rules on their API.

Using terraform acme certificate provider https://registry.terraform.io/providers/vancluever/acme/latest/docs/resources/certificate with the cloudflare dns service which hosts my zone (mydomain.com in example below) I began getting the error:

 Error: error creating certificate: error: one or more domains had a problem:
│ [mydomain.com] [mydomain.com] acme: error presenting token: 2 errors occurred:
│       * rpc error: code = Unknown desc = cloudflare: failed to find zone mydomain.com.: ListZonesContext command failed: Invalid request headers (6003)
│       * error encountered while presenting token for DNS challenge: rpc error: code = Unknown desc = cloudflare: failed to find zone mydomain.com.: ListZonesContext 

command failed: Invalid request headers (6003)
│ 
│ 
│ [www.mydomain.com] [www.mydomain.com] acme: error presenting token: 2 errors occurred:
│       * rpc error: code = Unknown desc = cloudflare: failed to find zone mydomain.com.: ListZonesContext command failed: Invalid request headers (6003)
│       * error encountered while presenting token for DNS challenge: rpc error: code = Unknown desc = cloudflare: failed to find zone mydomain.com.: ListZonesContext command failed: Invalid request headers (6003)

I ended up diving into the LEGO library which provides the ACME services and couldn't find many of these errors, and references to the error in google weren't helpful.

Upvotes: 0

Views: 1567

Answers (1)

Brian Horakh
Brian Horakh

Reputation: 617

After a bit of trial and effort and digging into the LEGO code.

I knew my token was good because I could use curl to access the cloudflare API passing the API token as the bearer.

The issue seems to triggered having either the CF_API_EMAIL + CF_API_KEY there is backward compatibility for CLOUDFLARE_EMAIL + CLOUDFLARE_EMAIL (this is same-same), but within the code there are two distinct routes for passing headers, one which includes email and one which does not.

Once I realized this my case was resolved by discarding the CLOUDFLARE_EMAIL & CLOUDFLARE_API_KEY (or CF_ equivalences), and using my single API token which I had granted both Zone:Read and DNS:Edit priviledges as the same value in CLOUDFLARE_DNS_API_TOKEN & CLOUDFLARE_ZONE_API_TOKEN ONLY and the error went away (so despite having a global API token, I treated them as separate tokens).

I had tried specifying those fields but if the CLOUDFLARE_EMAIL or CLOUDFLARE_API_KEY is set then the provider sends those headers and the API call fails.

I can't say exactly when/why this broke and it's possible (although unlikely) it could have been changes or other updates on my backend including potentially system level updates to lego, the tf provider, et al.

Hope this helps!

Upvotes: 3

Related Questions