47-дневные TLS-сертификаты: график и что автоматизировать

Коротко. Бюллетень CA/Browser Forum SC-081, принятый 11 апреля 2025 года, в три этапа сокращает максимальный срок действия публично доверенных TLS-сертификатов. Сертификаты, выпущенные с 15 марта 2026 года, могут действовать до 200 дней, с 15 марта 2027 года — до 100 дней, а с 15 марта 2029 года — до 47 дней. В те же даты сокращается и срок, в течение которого центр сертификации (CA) может повторно использовать проверку владения доменом: 200 дней, затем 100, затем 10. На практике каждый сертификат придётся выпускать и развёртывать автоматически (через ACME). Продлевать сертификаты следует в окне ARI, которое задаёт CA, и нужен мониторинг, который оповестит вас, пока ещё есть время исправить сломавшееся продление. Частных CA это не касается.

График

Правила записаны в разделах 6.3.2 и 4.2.1 Базовых требований (Baseline Requirements, BR) (версия 2.3.1, октябрь 2026 года). Бюллетень SC-081v3 внесла Apple, а поддержали его Sectigo, Google Chrome и Mozilla. Бюллетень прошёл голосование: 25 CA проголосовали «за», ни один не проголосовал «против», 5 воздержались, а все четыре производителя браузеров проголосовали «за».

Несколько деталей, которые важны, когда вы планируете работу под эти сроки:

• Это верхние границы, и CA соблюдают их при выпуске. Сертификат, выпущенный 14 марта 2026 года, ещё мог быть действителен 398 дней. Ничто не заставляет вас заменять его до истечения срока действия, но у сертификата на замену срок будет уже коротким.
• «Срок действия» включает обе границы. BR определяют его как период от notBefore до notAfter включительно и рекомендуют день запаса: срок действия сертификатов «SHOULD NOT» (не следует) превышать 199, 99 и 46 дней.
• Сокращение срока повторного использования проверки — более серьёзное изменение. Сейчас CA может месяцами повторно использовать подтверждение того, что домен example.com под вашим контролем. С 2029 года этому подтверждению должно быть не больше 10 дней, поэтому почти каждый выпуск потребует новой проверки владения доменом, и проверку (challenge) через DNS или HTTP тоже придётся автоматизировать.
• Сведения об организации в OV- и EV-сертификатах (название компании, адрес) можно повторно использовать 398 дней вместо 825.
• Область действия. BR регулируют серверные TLS-сертификаты публично доверенных CA. Сертификаты вашего собственного внутреннего CA, клиентские сертификаты и сертификаты S/MIME подчиняются другим правилам или не подчиняются никаким.

Какие сертификаты CA выпускают сегодня

20 октября 2026 года несколько крупных сайтов отдавали вот такие сертификаты. Вывод получен скриптом lifetimes.sh из раздела о мониторинге:

letsencrypt.org        Let's Encrypt              2026-09-04  ->  2026-12-03  (90 days)
www.google.com         Google Trust Services      2026-09-28  ->  2026-12-21  (84 days)
github.com             Sectigo Limited            2026-09-01  ->  2026-11-29  (90 days)
www.microsoft.com      Microsoft Corporation      2026-01-22  ->  2027-01-17  (360 days)
www.amazon.com         Amazon                     2026-01-19  ->  2027-01-11  (358 days)
www.digicert.com       DigiCert Inc               2026-10-11  ->  2026-11-26  (47 days)

Два сайта всё ещё отдают сертификаты почти на год, выпущенные в январе 2026 года, незадолго до того, как вступил в силу предел в 200 дней. DigiCert уже отдаёт на собственном сайте 47-дневный сертификат. Опубликованный план Let's Encrypt опережает требования BR:

• 13 мая 2026 года: профиль tlsserver, который нужно выбрать явно, выдаёт 45-дневные сертификаты.
• 10 февраля 2027 года: профиль по умолчанию classic выдаёт 64-дневные сертификаты, а авторизацию можно повторно использовать 10 дней.
• 16 февраля 2028 года: classic выдаёт 45-дневные сертификаты, а авторизацию можно повторно использовать 7 часов.

Действующий каталог ACME (directory) перечисляет профили, которые можно запросить уже сегодня:

"meta": {
  "profiles": {
    "classic": "https://letsencrypt.org/docs/profiles#classic",
    "shortlived": "https://letsencrypt.org/docs/profiles#shortlived",
    "tlsserver": "https://letsencrypt.org/docs/profiles#tlsserver"
  }
},
"renewalInfo": "https://acme-v02.api.letsencrypt.org/acme/renewal-info"

Что автоматизировать

При сертификатах на 398 дней ручное продление раз в год раздражало, но было терпимо. При 47-дневных сертификатах и 10-дневном повторном использовании проверки ручное продление — задача, в которой легко допустить ошибку, и выполнять её придётся не реже восьми раз в год для каждого имени, а если продлевать после двух третей срока действия, то почти двенадцать раз. Работа делится на четыре части.

1. Выпуск через ACME. Получайте каждый сертификат от публичного CA с помощью ACME-клиента (RFC 8555). Большинство коммерческих CA тоже предоставляют эндпоинты ACME, часто с привязкой внешнего аккаунта (external account binding). Если какой-то сертификат всё ещё приходит по почте, скачивается с портала или выдаётся по заявке, поставьте его в начало списка.

2. Проверка, которая проходит без присмотра. Выберите тип проверки (challenge), которому не нужен человек:

• http-01 требует, чтобы порт 80 был доступен на каждом хосте, который обслуживает это имя.
• dns-01 требует доступа к API DNS-провайдера. Если провайдер это позволяет, ограничьте права токена записями _acme-challenge.
• tls-alpn-01 работает целиком через порт 443.

Два более новых метода созданы именно для такой ситуации. Метод «DNS Labeled with Account ID» (тип проверки ACME dns-account-01, BR § 3.2.2.4.21) позволяет нескольким аккаунтам ACME проверять одно и то же имя, не борясь за единственную запись _acme-challenge. Метод «DNS TXT Record with Persistent Value» (§ 3.2.2.4.22, бюллетень SC-088) позволяет один раз опубликовать постоянную запись:

_validation-persist.example.com IN TXT "authority.example; accounturi=https://authority.example/acct/123; persistUntil=1782424856"

CA может считать каждую проверку этой записи действительной не более 10 дней. Но перепроверяет запись он сам, так что при каждом продлении никому не нужно править DNS. Прежде чем полагаться на этот метод, узнайте у своего CA, поддерживает ли он его.

3. Продление по указаниям CA. Продлевайте заранее и позвольте CA управлять сроками:

• Продлевайте, когда пройдёт около двух третей срока действия. Для 45-дневного сертификата это 30-й день. Let's Encrypt пишет, что «продлевать с жёстко заданным интервалом в 60 дней будет уже недостаточно». Начиная с версии 4.0 certbot продлевает сертификат, когда остаётся треть срока действия, а не за фиксированные 30 дней до истечения срока.
• Используйте ARI (RFC 9773), он описан в следующем разделе. CA сообщает каждому клиенту, когда продлевать сертификат, и может сдвинуть это окно на более ранний срок, если ему придётся массово отзывать сертификаты.
• Запрашивайте профиль явно, если вам нужны 45-дневные сертификаты раньше, чем ваш CA сменит профиль по умолчанию.

4. Развёртывание во все копии. Продлить файл на диске — ещё не всё. Перечислите все места, куда копируется сертификат:

• балансировщики нагрузки и CDN, в которые сертификаты загружают;
• секреты Kubernetes;
• хранилища ключей Java (keystore) и контейнеры PKCS#12;
• специализированные устройства (appliances), почтовые серверы, базы данных и брокеры сообщений;
• мобильные приложения, которые закрепляют конечный сертификат.

Для каждой копии нужен либо хук перезагрузки (reload hook), либо интеграция, которая сама забирает новый сертификат. Закрепление (pinning) конечного сертификата или его ключа в приложении при такой частоте продлений становится неработоспособным. Закрепляйте вместо этого ключ CA, а лучше не закрепляйте ничего.

В этом тесте certbot 5.8.0 работает с локальным ACME-сервером Pebble 2.10.1, профиль tlsserver которого выдаёт 45-дневные сертификаты. Тест показывает, что запрос профиля и настройки продления работают так, как описано в документации:

$ certbot certonly --standalone --non-interactive --agree-tos --register-unsafely-without-email \
    --server https://localhost:14000/dir -d app.example.test --preferred-profile tlsserver
Account registered.
Requesting a certificate for app.example.test
Successfully received certificate.
This certificate expires on 2026-12-04.
$ openssl x509 -in /etc/letsencrypt/live/app.example.test/cert.pem -noout -startdate -enddate
notBefore=Oct 20 11:47:52 2026 GMT
notAfter=Dec  4 11:47:51 2026 GMT
$ grep -E "preferred_profile|server" /etc/letsencrypt/renewal/app.example.test.conf
preferred_profile = tlsserver
server = https://localhost:14000/dir
$ certbot renew --non-interactive
Processing /etc/letsencrypt/renewal/app.example.test.conf
Certificate not yet due for renewal

certbot сохраняет профиль в настройках продления, поэтому каждое следующее продление снова запрашивает его. Флаг --preferred-profile появился в certbot 4.0. Если в каталоге CA указанного профиля нет, используется профиль CA по умолчанию. С --required-profile выпуск или продление в этом случае завершается ошибкой. Профили описаны в draft-ietf-acme-profiles; в октябре 2026 года этот черновик ожидал рассмотрения в IESG. У других клиентов флаги называются по-своему.

Сведения о продлении в ACME (ARI)

ARI (ACME Renewal Information, RFC 9773, июнь 2025 года) превращает выбор момента продления из догадки на стороне клиента в вопрос к CA. Для каждого сертификата клиент собирает идентификатор из двух его значений: идентификатора ключа центра сертификации (Authority Key Identifier) и серийного номера:

url = renewalInfo || '/' || base64url(AKI keyIdentifier) || '.' || base64url(Serial)

Затем клиент опрашивает этот URL без аутентификации. Ответ содержит suggestedWindow, а заголовок Retry-After сообщает, когда спросить снова. Этот запрос можно выполнить вручную для любого сертификата Let's Encrypt:

#!/bin/bash
set -e
host="$1"
openssl s_client -connect "$host:443" -servername "$host" </dev/null 2>/dev/null | openssl x509 -out cert.pem
aki=$(openssl x509 -in cert.pem -noout -ext authorityKeyIdentifier | grep -o -E '([0-9A-F]{2}:){19}[0-9A-F]{2}' | tr -d ':')
serial=$(openssl x509 -in cert.pem -noout -serial | cut -d= -f2)
# The DER INTEGER content keeps a leading 00 byte when the high bit is set.
[ $(( 16#${serial:0:1} )) -ge 8 ] && serial="00$serial"
b64url() { python3 -c 'import sys,base64; print(base64.urlsafe_b64encode(bytes.fromhex(sys.stdin.read().strip())).decode().rstrip("="))'; }
id="$(printf %s "$aki" | b64url).$(printf %s "$serial" | b64url)"
ari=$(curl -s https://acme-v02.api.letsencrypt.org/directory | grep -o '"renewalInfo": *"[^"]*"' | cut -d'"' -f4)
openssl x509 -in cert.pem -noout -issuer -startdate -enddate
echo "GET $ari/$id"
curl -s -D - "$ari/$id" | grep -i -E '^retry-after|^\{|"'

issuer=C=US, O=Let's Encrypt, CN=YE2
notBefore=Sep  4 14:34:32 2026 GMT
notAfter=Dec  3 14:34:31 2026 GMT
GET https://acme-v02.api.letsencrypt.org/acme/renewal-info/uVnyjs8i8IbTN0j_dhQYuoLYVYc.BUOTO-OGs6KzrdU08hA7yLZf
retry-after: 25769
{
  "suggestedWindow": {
    "start": "2026-11-02T17:18:36Z",
    "end": "2026-11-04T12:29:25Z"

Окно открывается через 59 дней после начала срока действия этого 90-дневного сертификата, когда прошло около двух третей срока. Клиенту следует выбрать случайный момент внутри окна: так продления распределяются во времени. Если CA придётся массово отзывать сертификаты, он сдвинет окно в прошлое, и корректно работающие клиенты продлят сертификаты в течение нескольких часов, а не сломаются в момент истечения срока действия. При продлении клиент передаёт идентификатор старого сертификата в поле replaces нового заказа (order).

Поддержка ARI в распространённых клиентах по их примечаниям к выпускам:

Мониторинг, который замечает сломавшееся продление

Автоматизация ломается незаметно: истёк токен API DNS-провайдера, изменение правил межсетевого экрана закрыло порт 80, перестал работать хук перезагрузки. Если 47-дневный сертификат продлевается на 30-й день, между первым неудачным продлением и сбоем остаётся около 17 дней. Оповещение должно прийти в начале этого промежутка.

Снаружи. Проверяйте все публичные имена, а не только те, о которых помните. Экспортер blackbox для Prometheus публикует момент истечения срока действия цепочки, которую отдаёт сервер, в метрике probe_ssl_earliest_cert_expiry:

probe_ssl_earliest_cert_expiry 1.795737599e+09
probe_success 1
probe_tls_version_info{version="TLS 1.3"} 1

Эти два правила оповещений проходят проверку promtool check rules (Prometheus 3.5.0). Первое срабатывает, когда продление просрочено, второе — когда сбой уже близко:

groups:
  - name: certificates
    rules:
      - alert: CertificateRenewalOverdue
        # Fires when less than a third of a 47-day lifetime (about 16 days) is left:
        # the renewal job should have replaced the certificate by now.
        expr: probe_ssl_earliest_cert_expiry - time() < 16 * 86400
        for: 1h
        labels:
          severity: warning
        annotations:
          summary: "{{ $labels.instance }}: certificate expires in {{ $value | humanizeDuration }}"
      - alert: CertificateExpiresSoon
        expr: probe_ssl_earliest_cert_expiry - time() < 7 * 86400
        for: 10m
        labels:
          severity: critical
        annotations:
          summary: "{{ $labels.instance }}: certificate expires in {{ $value | humanizeDuration }}"

Из скрипта. Команда openssl x509 -checkend N завершается с кодом 1, если срок действия сертификата истекает в ближайшие N секунд. Этого достаточно для задания cron или шага CI:

$ openssl x509 -in cert.pem -noout -enddate
notAfter=Nov 26 23:59:59 2026 GMT
$ openssl x509 -in cert.pem -noout -checkend $((30 * 86400)); echo "exit status: $?"
Certificate will not expire
exit status: 0
$ openssl x509 -in cert.pem -noout -checkend $((45 * 86400)); echo "exit status: $?"
Certificate will expire
exit status: 1

Сводная таблица в начале этой страницы получена этим скриптом:

#!/bin/bash
for host in "$@"; do
  openssl s_client -connect "$host:443" -servername "$host" </dev/null 2>/dev/null | openssl x509 -out /tmp/c.pem 2>/dev/null || { echo "$host: no certificate"; continue; }
  nb=$(openssl x509 -in /tmp/c.pem -noout -startdate | cut -d= -f2)
  na=$(openssl x509 -in /tmp/c.pem -noout -enddate | cut -d= -f2)
  issuer=$(openssl x509 -in /tmp/c.pem -noout -issuer -nameopt multiline | grep -E "organizationName" | head -1 | cut -d= -f2 | sed 's/^ *//')
  days=$(( ($(date -d "$na" +%s) - $(date -d "$nb" +%s) + 1) / 86400 ))
  printf '%-22s %-26s %s  ->  %s  (%s days)\n' "$host" "$issuer" "$(date -u -d "$nb" +%F)" "$(date -u -d "$na" +%F)" "$days"
done

Со стороны CA. Журналы Certificate Transparency (CT) фиксируют каждый сертификат, выпущенный для ваших доменов. Монитор CT показывает, какие продления состоялись и какие сертификаты появились неожиданно для вас. Прочитайте статью Certificate Transparency для разработчиков или посмотрите историю домена в инструменте истории CT. Чтобы понять, насколько готов ваш набор доменов, воспользуйтесь калькулятором срока действия сертификатов: он применяет график к каждому вашему сертификату.

CAA и привязка к аккаунту

Чем короче срок повторного использования проверки, тем больше проверок, и каждая из них сверяется с вашими записями CAA. С 15 марта 2027 года (бюллетень SC-098) CA также обязаны учитывать параметры accounturi и validationmethods из RFC 8657. С их помощью можно разрешить выпуск только для своего аккаунта ACME и только с выбранным типом проверки:

example.com. IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456789; validationmethods=dns-01"

Генератор записей CAA создаёт такие записи. Помните, что устаревшая запись CAA заблокирует ваши собственные продления, а они теперь происходят не реже восьми раз в год вместо одного.

Типичные ошибки

• Фиксированный интервал продления. Правило «продлевать каждые 60 дней» уже не работает для 45-дневных сертификатов. Продлевайте по доле срока действия или по ARI.
• Продление без перезагрузки. Новый файл лежит на диске, а сервер продолжает отдавать старый сертификат из памяти, пока у того не истечёт срок действия. Проверяйте хук развёртывания (deploy hook), а не только само продление.
• Забытые копии. Исходный сервер (origin) продлевает сертификат автоматически, а на CDN или балансировщике нагрузки всё ещё стоит сертификат, загруженный вручную.
• Оповещение за 7 дней. При 47-дневных сертификатах оповещение за неделю до истечения срока действия не оставляет времени разобраться с проблемой в DNS API или межсетевом экране. Оповещайте, когда продление просрочено.
• Закрепление ключей конечных сертификатов в мобильных приложениях или API-клиентах. Каждое продление с новым ключом ломает их.
• Уверенность, что частная PKI обязана перейти на те же сроки. Ваш внутренний CA может сохранить свою политику. Короткие сроки действия полезны и там, но это ваш выбор.

Источники

• CA/Browser Forum, Базовые требования (Baseline Requirements) v2.3.1: § 1.2.2 (ключевые даты), § 3.2.2.4.21–22 (новые методы проверки через DNS), § 4.2.1 (сроки повторного использования), § 6.3.2 (срок действия).
• Бюллетень SC-081v3 (принят 11 апреля 2025 года, вступил в силу 16 мая 2025 года).
• RFC 9773: расширение ACME Renewal Information. RFC 8555: протокол ACME. Черновик draft-ietf-acme-profiles.
• Let's Encrypt, Сокращение срока действия сертификатов до 45 дней и профили.
• Примечания к выпускам certbot, Caddy, lego, acme.sh и cert-manager.
• RFC 8659 (CAA) и RFC 8657 (параметры CAA accounturi и validationmethods).

Вывод команд получен 20 октября 2026 года в контейнерах node:24.22.0-trixie (OpenSSL 3.5.7, curl 8.14.1), certbot/certbot:v5.8.0 вместе с ghcr.io/letsencrypt/pebble:2.10.1, quay.io/prometheus/blackbox-exporter:v0.25.0 и prom/prometheus:v3.5.0.