диспетчер сертификатов не работает с ожиданием распространения запроса dns-01: не удалось определить полномочные серверы имен

Я создал cert-manager на aks-engine, используя команду ниже kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v0.12.0/cert-manager.yaml

моя спецификация сертификата

спецификация эмитента

Я использую nginx в качестве входа, я мог видеть txt-запись в зоне azure dns, создавая мой принцип службы azuredns, но не уверен, в чем проблема на серверах имен

Источник

3 ответа

Я столкнулся с той же ошибкой ... Я подозреваю, что это связано с тем, что я использую сочетание частных и общедоступных записей Azure DNS, и запись должна быть добавлена ​​​​к общедоступной записи, чтобы letsencrypt мог ее увидеть, однако cert-manager выполняет проверка того, что запись TXT видна, прежде чем просить letsencrypt выполнить проверку ... Я предполагаю , что записи DNS по умолчанию, на которые смотрит cert-manager, являются частными, и поскольку там нет записи TXT, он застревает на этой ошибке.

Способ обойти это, как описано на cert-manager.io , состоит в том, чтобы переопределить DNS по умолчанию с помощью extraArgs (я делаю это с помощью terraform и 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}"
  }
}
Источник

У меня была аналогичная ошибка, когда мой сертификат застрял в ожидании, и ниже показано, как я ее решил.

      kubectl get challenges 
urChallengeName

затем запустите следующее

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

и когда вы снова получаете проблемы, это должно исчезнуть

Источник

Проблема для меня заключалась в том, что мне не хватало некоторых аннотаций на входе:

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

В моем случае я используюhydrantidкак эмитент, но большинство людей используютletsencryptНаверное.

Источник
Другие вопросы по тегам