Сертификат cert-manager завис в ожидании DNS-проверки и упёрся в лимиты

Автоматическая выдача сертификатов через cert-manager выглядит магией ровно до первого сбоя. Поднимаешь выдачу через DNS-проверку, ждёшь сертификат, а он намертво застывает в состоянии ожидания распространения DNS-записи. Или того хуже, после череды экспериментов получаешь жёсткий отказ от центра сертификации с ошибкой о превышении лимита, и теперь неделю ничего нельзя выпустить. Оба сценария знакомы каждому, кто проходил это в продакшене. Разберём, почему проверка через DNS застревает, как её диагностировать и как не сжечь недельный лимит выдачи бессмысленными попытками.

Почему вообще выбирают проверку через DNS

Перед разбором проблем стоит понять, зачем вообще нужна именно эта проверка. У центра сертификации есть два основных способа убедиться, что домен ваш. Проверка через веб-сервер просит выложить определённое значение по особому пути на сайте. Проверка через DNS просит положить определённое значение в текстовую запись под именем домена.

Проверка через DNS сложнее в настройке, но решает задачи, недоступные веб-проверке. Главное, она позволяет выпускать сертификаты с подстановочным знаком, покрывающие сразу все поддомены. И она работает там, где веб-проверка не может, например когда узел спрятан за межсетевым экраном и недоступен снаружи по сети. Именно поэтому для подстановочных сертификатов и для внутренних сервисов выбирают проверку через DNS, несмотря на её капризность.

Как устроена проверка и где она застревает

Механика такая. cert-manager получает от центра сертификации значение, которое нужно положить в текстовую запись особого вида под доменом. Через подключённого поставщика DNS он создаёт эту запись, а затем ждёт, пока она распространится, и только потом сообщает центру сертификации, что можно проверять. Вот на этапе ожидания распространения чаще всего всё и застревает.

Прежде чем сообщить центру сертификации о готовности, cert-manager проводит собственную самопроверку: убеждается, что запись реально видна в DNS. Это сделано нарочно, чтобы не перегружать центр сертификации проваленными проверками из-за незавершённого распространения DNS или балансировщика. Если самопроверка не проходит, сертификат зависает в ожидании, и в статусе видно сообщение о том, что запись для домена ещё не распространилась.

Первое, что делают при зависании, это смотрят на ресурс проверки и его события.

# Посмотреть все проверки и их состояние
kubectl get challenges -A

# Подробности конкретной проверки, включая ошибки от поставщика DNS
kubectl describe challenge <имя-проверки>

В выводе ищут поле с ключом проверки, это и есть значение, которое должно появиться в текстовой записи. А в событиях находят любые ошибки от поставщика DNS. Именно здесь всплывают опечатки в настройке, нехватка прав у токена доступа и сетевые таймауты.

Почему самопроверка не видит запись, хотя она создана

Самая частая и сбивающая с толку ситуация: запись в DNS уже создана, видна в панели поставщика, а самопроверка cert-manager всё равно её не находит. Причина обычно в том, как именно cert-manager проверяет распространение.

По умолчанию он может проверять запись через внутренние резолверы кластера, которые не всегда видят свежесозданную публичную запись или вовсе не имеют доступа к публичным DNS-серверам. Если сеть кластера не позволяет cert-manager обращаться к публичным DNS-серверам для проверки записи, проверка зависает по таймауту, хотя запись физически существует. Лечится это явным указанием рекурсивных серверов имён, к которым cert-manager должен обращаться при самопроверке.

# Аргументы установки cert-manager
extraArgs:
  - --dns01-recursive-nameservers-only
  - --dns01-recursive-nameservers=8.8.8.8:53,1.1.1.1:53

Эти аргументы заставляют cert-manager проверять распространение только через указанные публичные серверы имён, минуя внутренние резолверы кластера. Для многих застрявших проверок это и есть решение. Если же запись действительно создана и серверы имён настроены верно, иногда нужно просто подождать: распространение DNS не мгновенно, и проверка решается сама через некоторое время.

Как настроить права токена доступа к DNS

Отдельный класс зависаний связан с правами токена, которым cert-manager управляет записями. Чтобы создавать текстовые записи особого вида для проверки, токену нужны определённые разрешения, и нехватка прав проявляется как ошибка от поставщика DNS в событиях проверки.

Токен сохраняют как секрет Kubernetes, и cert-manager использует его для добавления записей проверки. Права токена должны включать чтение настроек зоны, чтение самой зоны и, главное, редактирование записей DNS. Если ограничить токен только чтением, проверка упрётся в невозможность создать запись. Один и тот же токен обычно годится и для тестовой, и для боевой выдачи, так что создавать его нужно лишь однажды.

Почему стоит начинать с тестового сервера

Тут мы подходим к теме лимитов, и это критично. Всегда стоит начинать отладку с тестового сервера центра сертификации, чтобы не упереться в лимиты боевой инфраструктуры. Тестовая выдача даёт ненастоящие сертификаты, которым браузер не доверяет, но позволяет отлаживать всю цепочку без расхода боевых лимитов.

# Тестовый выдатчик для отладки
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging
spec:
  acme:
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    email: Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript.
    privateKeySecretRef:
      name: letsencrypt-staging

Тестовый сервер имеет несравнимо более щедрые лимиты, и именно на нём прогоняют все настройки до победного результата. Только убедившись, что выдача работает, переключаются на боевой сервер. Пропуск этого шага и есть главная причина сожжённых лимитов: люди отлаживают конфигурацию на боевой выдаче и за пару часов исчерпывают недельную квоту.

Какие лимиты центра сертификации важно знать

Лимиты у бесплатного центра сертификации жёсткие, и о ключевых надо помнить наизусть. Самый болезненный это лимит сертификатов на зарегистрированный домен: не более пятидесяти сертификатов на домен за неделю, и это включает обновления. Лимит глобальный, все заявки независимо от аккаунта считаются в эту квоту. Важнейший нюанс: поддомены одной зоны делят общий лимит зарегистрированного домена. То есть разные поддомены одного домена черпают из одной и той же квоты в пятьдесят штук.

Есть и другие лимиты. Дубликатов сертификата для одного и того же набора имён можно выпустить не более пяти за неделю. Новых заказов не более трёхсот за три часа на аккаунт. Имён в одном сертификате до ста. И отдельный лимит на проваленные проверки, который и наказывает за бездумную отладку: при многократных подряд провалах для одного имени аккаунт временно блокируется на запрос новых сертификатов для этого имени.

Здесь кроется коварство. Превышение лимита нельзя отменить или сбросить, остаётся только ждать, пока недельное окно сдвинется. Если выпустить двадцать пять сертификатов во вторник и двадцать пять в пятницу, следующие попытки откроются только со следующего вторника. Поэтому отладка на боевом сервере это прямая дорога к недельному простою.

Почему провальные попытки наказываются отдельно

Особого внимания заслуживает свежая политика против так называемых клиентов-зомби. Это заявители, которые раз за разом пытаются выпустить сертификат и проваливаются из-за просроченных доменов или неверной настройки DNS. Центр сертификации завёл учёт подряд идущих провалов проверки по паре аккаунт и домен и автоматически ставит на паузу проблемную выдачу.

Практический смысл прост: цикл из проваленных проверок при застрявшем DNS не просто бесполезен, он активно вредит, накапливая провалы и приближая блокировку. Поэтому при зависании проверки нельзя тупо пересоздавать сертификат снова и снова в надежде, что заработает. Сначала нужно понять причину зависания через осмотр ресурса проверки, починить настройку и только потом повторять. Способность накапливать провалы восстанавливается медленно, по чуть-чуть в день, и сбрасывается в ноль только при успешной проверке.

Какой приём упрощает делегирование проверки

Для сложных или часто меняющихся сценариев есть полезный приём с переадресацией записи проверки. Проверка через DNS обычно требует создать в основной зоне DNS особую запись-псевдоним, которая переадресует запросы проверки в отдельную зону, где клиент уже свободно создаёт нужные записи. Это разделяет управление основной зоной и зоной проверки, что удобно для безопасности и для случаев, когда не хочется давать cert-manager широкие права на основную зону.

Многие зависания при настройке через переадресацию вызваны как раз пропущенными шагами или опечатками при первичной настройке этой записи-псевдонима. Поэтому при проблемах первым делом проверяют, что псевдоним создан верно и указывает куда надо.

Какой стратегии придерживаться

Проблемы cert-manager с проверкой через DNS почти всегда сводятся к нескольким повторяющимся причинам, и дисциплина их закрывает. Всегда отлаживать на тестовом сервере центра сертификации, переключаясь на боевой только после успеха, чтобы не жечь недельные лимиты. При зависании сначала смотреть ресурс проверки и события, а не пересоздавать сертификат вслепую. Если самопроверка не видит созданную запись, явно указать публичные рекурсивные серверы имён. Убедиться, что у токена доступа есть права на редактирование записей, а не только чтение. И помнить про лимиты: пятьдесят сертификатов на домен за неделю с общей квотой для поддоменов и наказание за подряд идущие провалы.

Магия автоматической выдачи перестаёт ломаться, когда понимаешь, что за ней стоит цепочка из создания записи, её распространения, самопроверки и обращения к центру сертификации, и сбой может случиться в любом звене. Тот, кто при зависании просто давит на повтор, рискует упереться в недельную блокировку. А тот, кто читает статус проверки, чинит причину и отлаживает на тестовом сервере, получает сертификаты, которые выпускаются и продлеваются сами, без ночных тревог о просроченном шифровании.