Cert-manager: Cert-Manager does not create DNS records for (CloudFlare) DNS challenging

[gitnik]

Is this a BUG REPORT or FEATURE REQUEST?:
/kind bug

What happened:
I am trying to get cert-manager working together with nginx-ingress. I am however running into issues with dns validation via cloudflare. I am pretty sure the error is fairly easy to fix but I feel like the error messages aren't helping much.

I have an Issuer which uses cloudflare and letsencrypt:

apiVersion: certmanager.k8s.io/v1alpha1
kind: Issuer
metadata:
  name: letsencrypt
  namespace: default
spec:
  acme:
    server: https://acme-v01.api.letsencrypt.org/directory
    email: <redacted>
    privateKeySecretRef:
      name: letsencrypt
    dns01:
      providers:
        - name: cf-dns
          cloudflare:
            email: <redacted>
            # A secretKeyRef to a cloudflare api key
            apiKeySecretRef:
              name: cloudflare-secret
              key: apikey

I am looking to make use of the ingress-shim functionality (although I've tried creating a separate Certificate as well, but that's giving me the same result), via the following Ingress:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    certmanager.k8s.io/issuer: letsencrypt
    certmanager.k8s.io/acme-challenge-type: dns01
    certmanager.k8s.io/acme-dns01-provider: cf-dns
    ingress.kubernetes.io/ssl-redirect: "true"
    kubernetes.io/tls-acme: "true"
  name: <redacted>
  namespace: default
spec:
  rules:
    - host: <redacted>
      http:
        paths:
          - backend:
              serviceName: my-service
              servicePort: 80
            path: /
  tls:
      - hosts:
          - <redacted>
        secretName: <redacted>

After I create the Ingress, certificate creation is attempted and describing the certificate logs the following events:

Type     Reason                   Age              From                     Message
  ----     ------                   ----             ----                     -------
  Warning  ErrorCheckCertificate    1s (x7 over 3s)  cert-manager-controller  Error checking existing TLS certificate: secret "<redacted>-tls" not found
  Normal   PrepareCertificate       1s (x6 over 3s)  cert-manager-controller  Preparing certificate with issuer
  Normal   PresentChallenge         1s (x6 over 2s)  cert-manager-controller  Presenting dns-01 challenge for domain <redacted>
  Warning  ErrorPrepareCertificate  1s (x6 over 2s)  cert-manager-controller  Error preparing issuer for certificate: error presenting acme authorization for domain "<redacted>": Unexpected response code 'SERVFAIL' for _acme-challenge.<redacted>.

To my untrained eye it seems that this line indicates the failure:
Unexpected response code 'SERVFAIL' for _acme-challenge..

Checking the cloudflare console shows that no TXT entry has been created, leading me to believe this that that's what's causing the SERVFAIL response.

What you expected to happen:
I would expect cert-manager to have created the DNS entry in return hopefully resolving the error.

Environment:

• Kubernetes version: 1.9.1
• Cloud provider or hardware configuration**: Azure
• Install tools: Helm / cert-manager-0.2.9

[munnerz]

Can you try this again using cert-manager 0.3 and report back? There have been a number of changes to the way ACME validation is handled 😄

[gitnik]

I tried with 0.3 and it's still not working. But atleast I now get an actual error:

Error querying Cloudflare API -&gt; Get https://api.cloudflare.com/client/v4/zones?name=<domain>: net/http: invalid header field value "<key>\n" for key X-Auth-Key

I suppose the \n in the Auth Key is the issue. But who is causing this? Cloudflare or you guys?

[stiks]

I have had the same issue. Basically when you copy API Key from CloudFlare website, you copy extra symbol, not sure how, but it does appears.

If you copy your key from error message, and manually update cloudflare-secret, you'll not have that issue ;-)

[JustinHead]

It depends on how you are populating the Kubernetes Secret if it puts a trailing newline onto the secret data. You can see the difference if you do something such as echo -n <TOKEN> | base64 vs echo <TOKEN> | base64.

IMHO cert-manager should just strip the trailing newline from the token for user convience.

[gitnik]

Hah wow that was it! 😄 Thanks for the help!