I'm trying to order a certificate with cert-manager for my istio-ingress-gateway. For this i installed istio (1.2.2) on my kubernetes cluster (1.13.7) on AKS including cert-manager. After setting up a clusterissuer and ordering a certificate with a dns-01 challange against my azure-dns zone im getting the following error message in my cert-manager pod. This message gets spammed every ten seconds in the logs:

I0813 14:48:10.597656       1 controller.go:213] cert-manager/controller/challenges "level"=0 "msg"="syncing resource" "key"="istio-system/controller-certificate-531021094-0"
I0813 14:48:10.597940       1 dns.go:112] Checking DNS propagation for "<myurl>.westeurope.cloudapp.azure.com" using name servers: [10.0.0.10:53]
E0813 14:48:10.616908       1 sync.go:180] cert-manager/controller/challenges "msg"="propagation check failed" "error"="DNS record for \"<myurl>.westeurope.cloudapp.a
zure.com\" not yet propagated" "dnsName"="<myurl>.westeurope.cloudapp.azure.com" "resource_kind"="Challenge" "resource_name"="controller-certificate-531021094-0" "res
ource_namespace"="istio-system" "type"="dns-01"
I0813 14:48:10.616976       1 controller.go:219] cert-manager/controller/challenges "level"=0 "msg"="finished processing work item" "key"="istio-system/controller-certificate-53102
1094-0"

I installed istio with the following command:

helm install install/kubernetes/helm/istio --name istio --namespace istio-system \
  --values install/kubernetes/helm/istio/values-istio-sds-auth.yaml \
  --set gateways.istio-ingressgateway.sds.enabled=true \
  --set gateways.istio-egressgateway.enabled=false \
  --set certmanager.enabled=true \
  --set certmanager.email=<myemail> \
  --set certmanager.tag=v0.8.1 

I tried other cert-manager versions (6 + 8) as well but i got the same results. The seperate cert-manager installation gave me the same results.

This is the yaml file for my issuer...

apiVersion: certmanager.k8s.io/v1alpha1
kind: Issuer
metadata:
  name: letsencrypt-staging
  namespace: istio-system
spec:
  acme:
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    email: <myEmail>
    privateKeySecretRef:
      name: istio-ingressgateway-certs-private-key
    dns01:
      providers:
      - name: azure-dns
        azuredns:
          clientID: <myappID>
          clientSecretSecretRef:
            key: client-secret
            name: azuredns-config
          hostedZoneName: <myurl>.westeurope.cloudapp.azure.com
          resourceGroupName: <myresourcegroup> 
          subscriptionID: <mysubID> 
          tenantID: <mytenantID> 

...and for the certificate:

apiVersion: certmanager.k8s.io/v1alpha1
kind: Certificate
metadata:
  name: controller-certificate
  namespace: istio-system
spec:
  secretName: istio-ingressgateway-certs
  issuerRef:
    name: letsencrypt-staging 
  commonName: <myUrl>.westeurope.cloudapp.azure.com
  dnsNames:
  - <myUrl>.westeurope.cloudapp.azure.com
  acme:
    config:
    - dns01:
        provider: azure-dns
      domains:
      - <myUrl>.westeurope.cloudapp.azure.com

In azure i created a dns zone with the name <myurl>.westeurope.cloudapp.azure.com. Then i created an A record pointing at the istio-ingress-ip exposed by the cluster LoadBalancer. The following commands enables cert-manager to add the TXT entry in the dns zone required by letsencrypt. The first one creates a secret for the issuer and the second one creates a principal to access the dns-zone.

kubectl create secret generic azuredns-config -n istio-system --from-literal=client-secret=<myPW>

az ad sp create-for-rbac --name <myPrincipal>--role="DNS Zone Contributor" --scopes="/subscriptions/<mysubID>/resourceGroups/<myresourcegroup>"

The TXT entry is then successfully created in the dns zone but the certificate is not created as seen in the cert-manager logs above.

Im using https://digwebinterface.com to debug the dns-zone. When i use dig TXT _acme-challenge.myurl.westeurope.cloudapp.azure.com. @mygivennameserver im able to retrieve the acme token. When im trying this whithout the nameserver it is not working. As i understand it correctly this should also work when the propagation is through, right?

I've read that it takes up to 24h for azure to update the dns records. Does this also apply for TXT records?

I tried to enable cert-manager to the nameserver of the dns zone with the following installation. This gave me the same results except that the other nameservers are listed in the cert-manager log. Are there any mistakes in the installation?

helm install \
  --name cert-manager \
  --namespace istio-system \
  --version v0.9.1 \
  --set webhook.enabled=false \
  --set extraArgs='{--dns01-recursive-nameservers-only,--dns01-self-check-nameservers=8.8.8.8:53\,1.1.1.1:53\,<mynameserver>}' \
  jetstack/cert-manager

Running kubectl describe challenge -n istio-system results in:

Name:         controller-certificate-531021094-0
Namespace:    istio-system
Labels:       acme.cert-manager.io/order-name=controller-certificate-531021094
Annotations:  <none>
API Version:  certmanager.k8s.io/v1alpha1
Kind:         Challenge
Metadata:
  Creation Timestamp:  2019-08-13T14:43:57Z
  Finalizers:
    finalizer.acme.cert-manager.io
  Generation:  4
  Owner References:
    API Version:           certmanager.k8s.io/v1alpha1
    Block Owner Deletion:  true
    Controller:            true
    Kind:                  Order
    Name:                  controller-certificate-531021094
    UID:                   c740fea3-bdd8-11e9-80fd-0a58ac1f0fb7
  Resource Version:        31205901
  Self Link:               /apis/certmanager.k8s.io/v1alpha1/namespaces/istio-system/challenges/controller-certificate-531021094-0
  UID:                     c7d72ecf-bdd8-11e9-80fd-0a58ac1f0fb7
Spec:
  Authz URL:  https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/3805423
  Config:
    Dns 01:
      Provider:  azure-dns
  Dns Name:      <myurl>.westeurope.cloudapp.azure.com
  Issuer Ref:
    Name:    letsencrypt-staging
  Key:       bSjnfaFTApp6gPNsHc9-dPdmwsTwQJAd73CXmBrVc84
  Token:     Vn5Z7tBKajxnq1KrOBywP016VauoibCPcYsOESXhV4Q
  Type:      dns-01
  URL:       https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/3805423/RTxciA
  Wildcard:  false
Status:
  Presented:   true
  Processing:  true
  Reason:      Waiting for dns-01 challenge propagation: DNS record for "<myurl>.westeurope.cloudapp.azure.com" not yet propagated
  State:       pending
Events:
  Type    Reason     Age   From          Message
  ----    ------     ----  ----          -------
  Normal  Started    52m   cert-manager  Challenge scheduled for processing
  Normal  Presented  52m   cert-manager  Presented challenge using dns-01 challenge mechanism