Let's Encrypt перестал выдавать сертификат: запасные УЦ и план Б

MAATRIX

Certbot в cron отработал с ошибкой, домен вот-вот покажет посетителям «соединение не защищено», а перевыпуск через Let's Encrypt почему-то не проходит — то лимит, то таймаут, то challenge не проверяется. В этот момент разбираться в тонкостях ACME-протокола уже поздно: нужен рабочий план Б, который вы подготовили заранее. Разберём, какие есть запасные варианты — от альтернативных ACME-УЦ до самоподписанного сертификата — и как не остаться без HTTPS в критический момент.

Что происходит, когда Let's Encrypt отказывает

Прежде чем искать замену, стоит понять, с чем именно вы столкнулись — план Б для разных причин отличается.

Лимиты самого Let's Encrypt. У сервиса действуют ограничения на количество выпусков: не более определённого числа сертификатов на один домен за неделю, отдельный лимит на дублирующиеся сертификаты (тот же набор доменов), лимит на неудачные попытки авторизации. Точные цифры лимитов периодически меняются — смотрите актуальные значения в официальной документации Let's Encrypt перед тем, как на них ориентироваться. Упереться в них легко, если тестируете конфиг прямо на боевом ACME-эндпоинте вместо staging-окружения, или если автоматика зациклилась и долбит перевыпуском при каждом рестарте контейнера.

Сетевые проблемы до инфраструктуры Let's Encrypt. Валидация ACME требует, чтобы сервер Let's Encrypt достучался до вашего домена (HTTP-01, TLS-ALPN-01) или чтобы ваш клиент достучался до API центра (все типы challenge). Если с сети сервера есть проблемы с маршрутизацией или стабильностью до зарубежных сервисов — а администраторы из России такое периодически наблюдают на разных зарубежных сервисах, не только на CA — валидация может не проходить с таймаутами, которые на первый взгляд выглядят как «сертификат не выдаётся», хотя причина не в самом УЦ.

Технический сбой на стороне сервиса. Let's Encrypt — единая точка отказа для миллионов доменов. Инциденты редки, но случаются: если весь мир одновременно жалуется в статус-страницу сервиса, это не ваша конфигурация.

Маскирующаяся под «проблему с УЦ» ошибка конфигурации. Разъехались часы на сервере (TLS в принципе чувствителен к времени), файрвол блокирует порт 80 для HTTP-01, истёк ACME-аккаунт, DNS-запись для DNS-01 не успела распространиться. Это не повод менять УЦ — это повод исправить конфиг. Разбор типичных ошибок и их причин есть в статье про частые ошибки Let's Encrypt на сервере — стоит пройтись по чек-листу оттуда, прежде чем переключаться на запасной УЦ.

Если причина — первые два пункта, план Б действительно нужен. Если третий-четвёртый — чините корень проблемы, смена УЦ её не решит.

План Б №1: альтернативные ACME-совместимые УЦ

ACME — открытый протокол (RFC 8555), и Let's Encrypt не единственный, кто его реализует. На рынке есть и другие удостоверяющие центры с ACME-автоматизацией, которые могут выпускать бесплатные или условно-бесплатные DV-сертификаты (Domain Validation) точно так же автоматически, как Let's Encrypt — через HTTP-01 или DNS-01.

Ключевое отличие от Let's Encrypt у части таких УЦ — механизм External Account Binding (EAB): вам нужно заранее зарегистрироваться в личном кабинете УЦ, получить пару kid + hmac_key, и только с ними ACME-клиент сможет выпускать сертификаты от их имени. Это нельзя сделать «на лету» в момент аварии — регистрация и получение EAB-ключей должны быть готовы заранее.

Пример переключения certbot на альтернативный ACME-эндпоинт (адрес и EAB-ключи нужно подставить свои, из личного кабинета конкретного УЦ):

certbot certonly \
  --server https://acme.example-ca.tld/v2/DV \
  --eab-kid ВАШ_KID \
  --eab-hmac-key ВАШ_HMAC_KEY \
  -d example.com -d www.example.com \
  --webroot -w /var/www/html

Для acme.sh переключение УЦ ещё проще — он умеет хранить несколько зарегистрированных аккаунтов одновременно:

acme.sh --register-account -m you@example.com --server https://acme.example-ca.tld/v2/DV \
  --eab-kid ВАШ_KID --eab-hmac-key ВАШ_HMAC_KEY

acme.sh --issue -d example.com --server https://acme.example-ca.tld/v2/DV -w /var/www/html

Выбор между certbot и acme.sh как базовым инструментом разобран в статье certbot или acme.sh — что выбрать для сервера; для сценария «два УЦ про запас» удобнее оказывается acme.sh — он легче переключается между зарегистрированными аккаунтами без пересборки конфигурации с нуля.

Если вы используете Caddy с его встроенным авто-SSL — там тоже можно указать несколько issuer'ов, и при отказе одного Caddy попробует следующий. Общая идея конфига (конкретные названия директив уточняйте по документации вашей версии Caddy, они менялись между релизами):

example.com {
    tls {
        issuer acme {
            dir https://acme-v02.api.letsencrypt.org/directory
        }
        issuer acme {
            dir https://acme.example-ca.tld/v2/DV
            eab {
                key_id ВАШ_KID
                mac_key ВАШ_HMAC_KEY
            }
        }
    }
}

Практический момент: зарегистрируйте EAB-аккаунт во втором УЦ сейчас, даже если не планируете им пользоваться. Проверьте, что тестовый выпуск (можно на поддомене) проходит. Тогда в момент аварии вам останется поменять один параметр в конфиге, а не разбираться с личным кабинетом незнакомого сервиса под давлением времени.

План Б №2: российские УЦ — и подводный камень с доверием браузеров

Второй вариант — воспользоваться удостоверяющим центром, работающим в российской юрисдикции. Такие УЦ есть как коммерческие, так и государственный — Национальный удостоверяющий центр (НУЦ) Минцифры, который изначально создавался для выдачи сертификатов сайтам, оказавшимся без сертификата из-за прекращения обслуживания зарубежными УЦ.

Здесь есть важная оговорка, которую нельзя пропускать при выборе плана Б: корневой сертификат российского УЦ доверен не во всех браузерах по умолчанию. На конец лета 2026 года ситуация в общих чертах такая: браузеры на основе российских сборок Chromium (Яндекс Браузер, Атом и подобные) доверяют российским корневым сертификатам «из коробки», а значительная часть массовых браузеров (обычный Chrome, Firefox, Safari на разных ОС) — нет, если пользователь не установил корневой сертификат вручную. Конкретный список доверяющих браузеров и способ проверки лучше уточнять непосредственно перед принятием решения — он меняется.

Из этого следует практический вывод: сертификат от российского УЦ не универсальная замена Let's Encrypt, а решение под конкретную аудиторию:

• Если сайт или сервис ориентирован в основном на российских пользователей, которые с высокой вероятностью используют браузер с доверием к российским корневым сертификатам (или у которых корневой сертификат уже установлен централизованно, например в корпоративной среде) — вариант рабочий.
• Если аудитория смешанная или преимущественно за пределами такой экосистемы — часть посетителей вместо ошибки «сертификат просрочен» увидит другую: «сертификат выдан неизвестным центром», что для обычного пользователя выглядит не менее тревожно.
• Для API, серверных интеграций и мобильных приложений, где вы полностью контролируете доверенное хранилище клиента (например, добавляете корневой сертификат в бандл приложения сами) — ограничение снимается, и это делает такой УЦ хорошим вариантом именно для внутренних и B2B-интеграций.

Оформление сертификата в российском УЦ обычно требует юрлицо или ИП и подтверждение владения доменом — процесс не такой мгновенный, как ACME-автоматизация у зарубежных центров, поэтому и здесь действует то же правило: оформлять заранее, а не в момент, когда старый сертификат уже просрочен.

План Б №3: самоподписанный сертификат как временная мера

Самый быстрый вариант — сгенерировать сертификат самому, без какого-либо УЦ:

openssl req -x509 -nodes -newkey rsa:2048 \
  -keyout /etc/ssl/private/example.com.key \
  -out /etc/ssl/certs/example.com.crt \
  -days 14 \
  -subj "/CN=example.com"

Это займёт секунды и снимет одну проблему — соединение снова будет зашифровано TLS. Но важно чётко понимать, какую проблему это не решает:

• Любой браузер обычного посетителя покажет предупреждение вида «Соединение не защищено» / «NET::ERR_CERT_AUTHORITY_INVALID» — не мелкий значок, а полноэкранное предупреждение, которое отпугнёт значительную часть пользователей.
• HSTS, если он у вас включён на домене, может вообще заблокировать доступ без явного исключения — браузер откажется даже показать кнопку «продолжить, я понимаю риск».
• Клиенты API со строгой проверкой сертификата (большинство HTTP-библиотек по умолчанию) просто перестанут соединяться с ошибкой валидации цепочки — это не «предупреждение», а обрыв соединения.
• Платёжные шлюзы, вебхуки от сторонних сервисов, мобильные приложения со встроенным pinning — всё это ломается на самоподписанном сертификате без ручного вмешательства с обеих сторон.

Разбор того, где самоподписанные сертификаты — это нормальная практика, а где — антипаттерн, есть в статье антипаттерн: самоподписанный сертификат внутри сети. Для внешнего публичного сайта это временная мера на часы, а не на дни — и обязательно с планом, что делать дальше.

Разумные сценарии применения:

• Внутренние сервисы и админ-панели, где список посетителей известен и они могут один раз добавить исключение или ваш корневой сертификат в доверенные.
• Служебная связь между вашими же серверами (API-to-API), где вы контролируете обе стороны и можете зафиксировать (запинить) конкретный отпечаток сертификата вместо полной проверки цепочки — тогда самоподписанный сертификат ничем не хуже коммерческого.
• Мост на несколько часов, пока идёт оформление в резервном УЦ, — с баннером на сайте или статус-страницей, предупреждающей пользователей, и обязательно с понятным сроком, когда это закончится.

Не стоит держать самоподписанный сертификат на публичном сайте дольше, чем необходимо для переключения на нормальный план Б — доверие, потерянное из-за пугающего предупреждения в браузере, восстанавливается куда дольше, чем занимает сама починка.

Настраиваем запасной контур заранее, а не во время аварии

Всё, что описано выше, работает как план Б только если подготовлено до инцидента. В момент, когда основной сертификат уже просрочен, у вас нет времени регистрироваться в новом УЦ, ждать одобрения EAB-ключей или разбираться с синтаксисом чужого ACME API.

Что стоит сделать заранее, пока всё работает:

1. Зарегистрировать аккаунт минимум в одном альтернативном ACME-УЦ и сохранить его EAB-ключи в менеджере секретов (не в открытом виде в репозитории).
2. Один раз выпустить тестовый сертификат через резервный УЦ — на поддомене или в staging-окружении, — чтобы убедиться, что DNS, файрвол и права на webroot действительно позволяют пройти challenge именно с этим УЦ. Некоторые УЦ предъявляют чуть другие требования к challenge, чем Let's Encrypt.
3. Держать скрипт генерации самоподписанного сертификата в репозитории с runbook — не изобретать команду openssl req в панике, а взять готовую и проверенную.
4. Учитывать срок действия сертификата при выборе резервного УЦ. У Let's Encrypt сертификаты действуют 90 дней, что вынуждает к частому автопродлению и частым же возможностям споткнуться. У части коммерческих УЦ срок действия может быть больше (в рамках отраслевого ограничения CA/Browser Forum — не более 398 дней для публичных DV-сертификатов). Более длинный срок у резервного УЦ снижает частоту, с которой вам вообще придётся об этом думать, — это не замена автоматизации, а дополнительный запас времени на её починку.
5. Проверять DNS-01 как более отказоустойчивый способ валидации, если ваш регистратор или DNS-провайдер даёт на это API. DNS-01 не зависит от того, дотягивается ли внешний валидатор до порта 80 вашего сервера, и единственный способ получить wildcard-сертификат (*.example.com).

Практический чек-лист: не остаться без HTTPS

Отдельно стоит настроить мониторинг не только истечения сертификата, но и самого домена — записи DNS и делегирование тоже могут «сломаться тихо» и выглядеть как проблема с сертификатом. Практика такого мониторинга разобрана в статье мониторинг сертификатов и доменов.

Держать полный контроль над сервером — своими руками менять конфиг nginx или Caddy, ставить cron-джобы для dry-run, хранить несколько ACME-аккаунтов — проще на VPS, где у вас есть root-доступ и вы не зависите от того, что панель управления хостера разрешает делать с сертификатами.

Частые вопросы