Cloudflare DNS resolver fails: Error: 6003: Invalid request headers #3021
Comments
|
Getting this too with API keys as well as the API tokens being broken |
|
Also experiencing this, noticing this error: |
|
Did anyone resolve this issue yet? I'm having to manually renew expiring certs and its not fun. |
|
Yep this is broken. With global and origin key. |
|
For what it's worth, I found and followed this article and somehow this started working again for me. Not sure what was done differently in this article than what I was doing, but it started working for me 🤷♂️ |
|
@rklubenspies which is not on the official documentation.. I had previous issues with the webhook validation but resolved it (#2918 (comment)), maybe it is relate to that 🤨 |
|
@ltetrel I think this might have something to do with it—I didn't notice this until you pointed it out, but this is definitely something I didn't set the first time around. |
|
Still having the same issue even after strictly following https://blog.darkedges.com/2020/05/04/cert-manager-kubernetes-cloudflare-dns-update/ .. |
|
@ltetrel Another thing I had to do was restart all the |
|
Is everything solved now? /triage needs-information |
jetstack-bot
added
the
triage/needs-information
|
Hi, Sadly no. I rely on a certificate I manually asked from certbot and injected into the k8s cluster for now. |
|
It needs valid DNS resolvers to look up the SOA record to find the zone to use in Cloudflare |
|
Running into the exact same issue. Disabling the validation did not fix this |
|
OK so using a new API Token instead of the global one works, as we had set apiTokenSecretRef |
|
I did fixed with global token using |
|
I am running |
|
I'm using cert-manager v0.12.0. This is working when I use the Global API key from the admin account. |
|
@timothyclarke this got solved in newer releases of cert-manager |
|
@ltetrel I am currently running cert-manager v1.0.4 (Kubernetes v1.19.4) and still get the same behavior. Creating ClusterIssuer: After requesting a new certificate, the certificaterequest is stuck in pending state: And the challange has the error: Controller Logs during this Workflow (Certificate Creation): Not quiet sure what's causing this, I will keep on trying and let you know if I find any solution to it. |
|
siggghhh, I tried different reconfigurations etc. but as it turns out the 5th new generated Cloudflare API Token somehow worked. I don't think it really made a difference that I started double quoting the String in the secret. Maybe someone else encountering this issue can confirm, that a new, correct API Token resolves this issue. Cert-Manager documented which access roles are required: https://cert-manager.io/docs/configuration/acme/dns01/cloudflare/#api-tokens. For my part, idk what the problem with my first attempts was... |
|
I'm facing a similar problem. I tried to use |
|
@luishdez which version of certmanager are you running? I'm on the latest version of certmanager, your yaml simply results in |
|
I was just able to deploy it using an api token generated from cloudflare. Follow the steps here : but, instead of using apiKeySecretRef, using a token here, use apiTokenSecretRef. You do not need to base64 encode the secret. I read somewhere else that they only got it to work by doing that, so I was on the wrong track. |
|
I've just been setting this up myself and was curious why my apiTokenSecretRef was not working. Turns out it does work if I don't base64 encode the secret. This seems odd and I don't know enough to dig through and find out why this is the case. |
Ignore me, this was my lack of understanding of the difference between data and stringData! |
|
I got the same error, but created a new token with these permissions, that worked perfectly: I'm sure you can make a more restrictive key, but atleast these works :) |
|
For what it's worth I was able to fix my issue by changing from the documented
I'm using API Token from Cloudflare with a export API_TOKEN=$(echo -n '-myVeryS3cretAPITokenfromCloudfl4re' | base64)
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
name: cloudflare-api-token-secret
namespace: cert-manager
type: Opaque
data:
api-token: ${API_TOKEN}
EOFBefore those changes I was seeing the below errors:
|
|
Issues go stale after 90d of inactivity. |
jetstack-bot
added
the
lifecycle/stale
|
Stale issues rot after 30d of inactivity. |
jetstack-bot
added
lifecycle/rotten
|
Rotten issues close after 30d of inactivity. |
|
@jetstack-bot: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
This got me thinking as I just had this problem on a new cluster and api key. This is happening when the cloudflare api key has a |
Yeah looks like it was that for me, added this to my cert-manager:
deploymentAnnotations:
certmanager.k8s.io/disable-validation: "true"Then applied and it started working |
|
This issue seems to be closed but I don't see an associated PR with it to fix this bug (#3021 (comment)) I don't think disabling validation should be considered a fix. |
|
I was able to resolve the issue by both not having a hyphen and by not base64 encoding the API token. |
Getting this in Edit - I had an /reopen |
|
@ameyp: You can't reopen an issue/PR unless you authored it or you are a collaborator. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Confirm changing |
Describe the bug:
Cannot get DNS resolver to work with cloudflare account
Expected behaviour:
The challenge to be accepted
Steps to reproduce the bug:
I strictly followed the documentation with an
api-token:https://cert-manager.io/docs/configuration/acme/dns01/cloudflare/#api-tokens
Tried also with the global
api-key.Anything else we need to know?:
The HTTP does not work neither.
Environment details::
v1.18.3opennebula/kind bug
The text was updated successfully, but these errors were encountered: