2026-10-26

Сертификаты теперь живут 200 дней, у Let's Encrypt скоро 64: что проверить

Коротко: с 15 марта 2026 года публичный TLS-сертификат (по привычке его называют SSL-сертификатом) нельзя выпустить дольше чем на 200 дней, раньше было 398. В марте 2027 года потолок станет 100 дней, в марте 2029-го 47. Let's Encrypt с 10 февраля 2027 года по умолчанию выдаёт сертификаты на 64 дня вместо 90. Если продление работает само и сервер подхватывает новый сертификат, делать ничего не нужно. Проблемы будут там, где сертификат меняют руками или продлевают по жёсткому расписанию в cron, и там, где сервер после продления не перезагружают.

Что изменилось и почему#

Сроки задаёт CA/Browser Forum, объединение удостоверяющих центров и разработчиков браузеров. В апреле 2025 года оно приняло бюллетень SC-081v3: за проголосовали 25 удостоверяющих центров и все четыре браузера, пятеро воздержались, против не было никого. Срок сокращают в три шага:

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

Let's Encrypt идёт с запасом. В объявлении от 7 октября 2026 года сказано: с 10 февраля 2027 года сертификат по умолчанию живёт 64 дня, последний 90-дневный истечёт примерно 11 мая 2027 года, а на 2028 год запланированы 45 дней. В тестовой среде (staging) 64-дневные сертификаты выдают уже с 14 октября 2026 года.

Где сломается#

Сертификат, который ставят руками. Если его покупали на год и раз в год вспоминали про продление, теперь вспоминать придётся дважды в год, с 2027 года четыре раза, с 2029-го примерно восемь. При таком ритме ручную замену легко пропустить.

Продление по жёсткому расписанию. Запуск certbot «раз в 60 дней» для 90-дневного сертификата оставлял месяц запаса. Для 64-дневного запас сжимается до четырёх дней, и одна неудачная попытка продления превращается в просроченный сертификат.

Продлили, а сервер отдаёт старый. Новый файл лёг на диск, но nginx, балансировщик или приложение держат старый сертификат в памяти, пока их не перезагрузят.

Сертификат разложен по нескольким местам. Балансировщик, CDN, секрет в Kubernetes, копия на втором сервере. Если обновление доезжает не везде, часть запросов пойдёт с просроченным сертификатом.

Пиннинг сертификата в приложении. Мобильное приложение или клиентский скрипт, который проверяет отпечаток конкретного сертификата сервера, ломается при каждом продлении. Если пиннинг нужен, его делают на открытый ключ или на промежуточный сертификат, и всё равно держат запасной вариант.

Сертификаты частного удостоверяющего центра внутри компании правила CA/Browser Forum не касаются. Сертификаты НУЦ Минцифры тоже: это не публично доверенный центр, и браузеры, кроме Яндекс Браузера, ему по умолчанию не доверяют. Почему API за таким сертификатом не открывается в curl и как это исправить, рассказано в статье про Russian Trusted Root CA.

Как настроить продление Let's Encrypt#

1. ACME-клиент с поддержкой ARI. ARI (ACME Renewal Information) позволяет удостоверяющему центру самому подсказать клиенту, когда продлевать. Let's Encrypt пишет, что клиентам с ARI ничего менять не нужно. Поддерживает ли ARI ваш клиент, смотрите в его документации.
2. Продление по доле срока, а не по календарю. Let's Encrypt советует продлевать примерно на двух третях срока: для 64-дневного сертификата это 43-й день. Поищите в cron-заданиях, обёртках и регламентах числа 60, 80 и 83.
3. Перезагрузку после продления. У certbot для этого есть --deploy-hook, у других клиентов похожие хуки. Команда вроде systemctl reload nginx должна выполняться автоматически после каждого успешного продления.
4. Оповещение о неудачном продлении. На письма от удостоверяющего центра не рассчитывайте: Let's Encrypt, например, перестал присылать напоминания об истечении в 2025 году.
5. Пробный прогон в staging. Пока до февраля есть время, выпустите тестовый сертификат в staging Let's Encrypt и проверьте всю цепочку: выпуск, установку, перезагрузку и ответ сервера. Адрес staging для ACME-клиента https://acme-staging-v02.api.letsencrypt.org/directory, у certbot для этого есть ключ --test-cert.

Как посмотреть срок действия сертификата на сервере#

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

echo | openssl s_client -connect api.example.com:443 \
  -servername api.example.com 2>/dev/null \
  | openssl x509 -noout -dates -issuer

Строка notAfter это конец срока действия: после этой даты браузеры и клиенты сертификат отвергают. Ключ -servername лучше не убирать: новые версии OpenSSL подставляют имя из -connect сами, но при подключении по IP или на старой версии без него сервер с несколькими сайтами отдаст сертификат другого домена.

То же видно в curl -v https://api.example.com: в выводе есть строки start date и expire date. Если сертификат уже истёк, curl завершится с кодом 60 и, в зависимости от сборки, напишет SSL certificate problem: certificate has expired или общее SSL peer certificate or SSH remote key was not OK.

Для мониторинга ту же команду превращают в условие: с ключом -checkend openssl завершается с ненулевым кодом, если сертификат истекает раньше чем через заданное число секунд. 14 дней это 1209600 секунд:

echo | openssl s_client -connect api.example.com:443 \
  -servername api.example.com 2>/dev/null \
  | openssl x509 -noout -checkend 1209600

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

Сертификат уже истёк: что делать#

Chrome в этом случае показывает NET::ERR_CERT_DATE_INVALID, Firefox пишет SEC_ERROR_EXPIRED_CERTIFICATE, curl завершается с кодом 60.

1. Посмотрите, что отдаёт сервер, командой из предыдущего раздела. Если notAfter в прошлом, а файл на диске свежий, сервер не перезагрузили: хватит systemctl reload nginx или аналога.
2. Если свежего файла нет, продлите вручную: sudo certbot renew, и прочитайте ошибку в выводе. Частые причины: порт 80 закрыт для проверки HTTP-01, DNS домена смотрит на другой сервер, у DNS-проверки истёк API-токен провайдера.
3. Если сервер отдаёт действующий сертификат, а ошибка только у одного пользователя, проверьте часы на его устройстве: когда дата убежала вперёд, клиент считает сертификат просроченным.

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

Шпаргалка#

• До 10 февраля 2027: максимум 200 дней у всех публичных центров, у Let's Encrypt 90.
• С 10 февраля 2027: Let's Encrypt выдаёт 64 дня. С 15 марта 2027: потолок 100 дней.
• Настроить: ARI или продление на двух третях срока, перезагрузку после продления, оповещение о сбое.
• Проверить: openssl s_client ... | openssl x509 -noout -dates по сетевому адресу, а не по файлу.