cert manager is failing with Waiting for dns-01 challenge propagation: Could not determine authoritative nameservers

Question

I have created cert-manager on aks-engine using below command kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v0.12.0/cert-manager.yaml

my certificate spec

issuer spec

Im using nginx as ingress, I could see txt record in the azure dns zone created my azuredns service principle, but not sure what is the issue on nameservers

I found the cause for it, it is because of the default name server when installed cert-manager. — Vineesha.C, May 13 '20 at 04:11

score 9 · Accepted Answer · answered Feb 04 '21 at 09:40

I ran into the same error... I suspect that it's because I'm using a mix of private and public Azure DNS entries and the record needs to get added to the public entry so letsencrypt can see it, however, cert-manager performs a check that the TXT record is visible before asking letsencrypt to perform the validation... I assume that the default DNS records cert-manager looks at is the private one, and because there's no TXT record there, it gets stuck on this error.

The way around it, as described on cert-manager.io is to override the default DNS using extraArgs (I'm doing this with terraform and helm):

resource "helm_release" "cert_manager" {
  name       = "cert-manager"
  repository = "https://charts.jetstack.io"
  chart      = "cert-manager"
  
  set {
    name  = "installCRDs"
    value = "true"
  }
  
  set {
    name  = "extraArgs"
    value = "{--dns01-recursive-nameservers-only,--dns01-recursive-nameservers=8.8.8.8:53\\,1.1.1.1:53}"
  }
}

If you are using helm direct, you can set the extraArgs like that: `--set extraArgs='{--dns01-recursive-nameservers-only,--dns01-self-check-nameservers=8.8.8.8:53\,1.1.1.1:53}'` — Thalles Noce, Oct 18 '21 at 13:46

score 0 · Answer 2 · answered Aug 19 '22 at 12:05

0

The issue for me, was that I was missing some annotations in the ingress:

cert-manager.io/cluster-issuer: hydrantid
kubernetes.io/tls-acme: 'true'

In my case I am using hydrantid as the issuer, but most people use letsencrypt I guess.

answered Aug 19 '22 at 12:05

ccoutinho

3,308
5
39
47

score 0 · Answer 3 · answered Dec 09 '22 at 13:32

I had similar error when my certificate was stuck in pending and below is how i resolved it

kubectl get challenges 
urChallengeName

then run the following

kubectl patch challenge/urChallengeName -p '{"metadata":{"finalizers":[]}}' --type=merge

and when u do get challenges again it should be gone

cert manager is failing with Waiting for dns-01 challenge propagation: Could not determine authoritative nameservers

3 Answers3