Canary-выкатка и ротация PEM Let’s Encrypt без простоя в Nginx и Apache

Цель: обновлять и ротировать PEM-сертификаты Let’s Encrypt так, чтобы пользователи не ловили TLS-ошибки, а вы могли безопасно раскатить изменения по инфраструктуре через canary и откатиться за минуты.

Зачем вообще canary для TLS и при чём тут PEM-ротация

Само продление Let’s Encrypt обычно проходит гладко, но на продакшене чаще ломается не ACME, а эксплуатационные мелочи: сервер прочитал «частично записанный» PEM, вы случайно отдали cert.pem без цепочки, или перепутали ключи между доменами.

Поэтому практичная стратегия состоит из двух частей:

• PEM-ротация без частичной записи: не редактировать боевые файлы «на месте», а переключать их атомарно.
• Canary-выкатка: сначала обновить один узел или один виртуальный хост, понаблюдать, затем раскатить на остальных.

Важно понимать, что «без простоя» для TLS — это не «процесс не падал», а отсутствие всплесков handshake-ошибок и жалоб клиентов, особенно API-интеграций и старых сред.

Как Nginx и Apache загружают сертификаты при reload

Нужно знать один принцип: и Nginx, и Apache читают сертификат и ключ из файлов в момент (пере)инициализации рабочих процессов. Если в этот момент файл битый или неполный, вы получите ошибки рукопожатия.

• Nginx: при nginx -s reload мастер перечитывает конфиг, поднимает новые воркеры и плавно выводит старые. Активные соединения обычно не рвутся, если не делать жёсткий рестарт.
• Apache: apachectl graceful (или systemctl reload) выполняет мягкую перезагрузку воркеров, стараясь не обрывать активные запросы.

Главное правило ротации: не перезаписывайте боевой PEM редактором и не делайте «cat > файл.pem» в путь, который читает веб-сервер. Готовьте новые файлы отдельно и переключайте атомарно.

Структура файлов Let’s Encrypt и что указывать в конфиге

В типичной установке Certbot в /etc/letsencrypt/live/yourdomain/ лежат симлинки на текущую версию из /etc/letsencrypt/archive/…. Обычно встречаются:

• privkey.pem — приватный ключ;
• cert.pem — leaf-сертификат;
• chain.pem — intermediate-цепочка;
• fullchain.pem — cert + chain (то, что чаще всего нужно для сервера).

Практическая рекомендация:

• Nginx: ssl_certificate → fullchain.pem, ssl_certificate_key → privkey.pem.
• Apache: SSLCertificateFile → fullchain.pem, SSLCertificateKeyFile → privkey.pem (в зависимости от версии/сборки цепочка может задаваться отдельно, но fullchain.pem обычно закрывает вопрос).

Если отдать только cert.pem без цепочки, часть клиентов получит ошибку «unknown issuer» или «incomplete chain». Canary-выкатка помогает поймать это до массового раската.

Если сертификат обслуживает публичный сайт, не забывайте про «обвязку»: корректный домен и DNS, стабильная инфраструктура и понятные права на ключи. Для небольших проектов это часто удобнее вести на виртуальном хостинге, а для нескольких фронтендов и canary-выкаток по узлам — на VDS.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Атомарная ротация PEM: два рабочих паттерна

Идея всегда одна: собрать/обновить артефакты отдельно, проверить, затем переключить «боевой» путь атомарной операцией (в пределах одной файловой системы) и выполнить reload.

Вариант A: «боевой» каталог с симлинками

Создайте свой стабильный путь, который будет указан в конфиге веб-сервера, и внутри держите симлинки на актуальные файлы Let’s Encrypt:

sudo install -d -m 0750 /etc/ssl/local/example.com
sudo ln -sfn /etc/letsencrypt/live/example.com/fullchain.pem /etc/ssl/local/example.com/fullchain.pem
sudo ln -sfn /etc/letsencrypt/live/example.com/privkey.pem /etc/ssl/local/example.com/privkey.pem

Плюсы:

• переключение происходит быстро и предсказуемо;
• можно легко организовать откат на предыдущую версию (если вы фиксируете, на что указывали ссылки до переключения).

Вариант B: сборка нового файла и атомарный mv

Полезно, когда вы хотите исключить рассинхронизацию «сертификат обновился, а ключ — нет» в ваших собственных путях. Готовите новый файл рядом и заменяете атомарно:

sudo install -d -m 0750 /etc/ssl/local/example.com
sudo cat /etc/letsencrypt/live/example.com/fullchain.pem /etc/letsencrypt/live/example.com/privkey.pem > /etc/ssl/local/example.com/bundle.pem.new
sudo chmod 0640 /etc/ssl/local/example.com/bundle.pem.new
sudo mv /etc/ssl/local/example.com/bundle.pem.new /etc/ssl/local/example.com/bundle.pem

Ограничение: не все конфигурации ожидают «cert+key в одном файле». Для Nginx чаще остаются на двух путях (сертификат отдельно, ключ отдельно), и это нормально.

Предпроверки перед canary и reload (чтобы не устроить аварию)

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

1) Проверка соответствия ключа и сертификата

Сравните отпечатки публичного ключа:

openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem -noout -pubkey | openssl pkey -pubin -outform der | openssl dgst -sha256
openssl pkey -in /etc/letsencrypt/live/example.com/privkey.pem -pubout -outform der | openssl dgst -sha256

Хэши должны совпасть.

2) Проверка цепочки локально

openssl verify -CAfile /etc/letsencrypt/live/example.com/chain.pem /etc/letsencrypt/live/example.com/cert.pem

Ожидаемый результат: OK.

3) Проверка «как увидит клиент» после reload

openssl s_client -connect 127.0.0.1:443 -servername example.com -showcerts < /dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Для canary проверяйте именно конкретный узел (его IP), а не балансировщик.

Canary certificate: три схемы, которые реально работают

В TLS canary обычно означает «часть инфраструктуры получает новый сертификат раньше остальных», а не попытку разделить сертификаты на одном IP для случайной доли клиентов.

Схема 1: один узел из пула

Если у вас 2+ фронтенда за балансировщиком, обновите один фронтенд и понаблюдайте 10–30 минут (или ваш стандарт): логи, метрики, жалобы API-клиентов. Если чисто — раскатывайте дальше.

Схема 2: отдельный canary-вхост или порт

Когда нужно прогнать «настоящих» клиентов без риска для основного трафика, поднимают отдельный vhost (например, canary.example.com) или отдельный порт (например, 8443) и кладут туда новый сертификат.

Это особенно полезно, если есть mTLS, пиннинг у части клиентов или нестандартные корпоративные цепочки доверия.

Схема 3: SNI-canary по одному имени

Если на одном фронте обслуживается много доменов, можно первым делом обновить сертификат только для одного имени/SAN-набора и наблюдать. Это canary «по SNI».

Nginx: безопасный reload сертификата без обрыва соединений

Правильный порядок: сначала тест конфига, затем reload, затем проверка выдаваемого сертификата.

Шаг 1: проверьте конфиг

sudo nginx -t

Шаг 2: выполните reload

sudo systemctl reload nginx

Альтернатива:

sudo nginx -s reload

Шаг 3: убедитесь, что сертификат реально обновился

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

Типичные грабли в Nginx при ротации

• Права на ключ: воркерам нужно читать файл, указанный в ssl_certificate_key. Проверьте владельца/права и группу, принятую у вас для ключей.
• Частичная запись: «перезаписали файл» вместо атомарной подмены.
• Перепутанные домены: в автоматизации легко указать чужой privkey.pem или не тот каталог.

Apache: graceful-обновление сертификата и контроль состояния

В Apache цель та же: обойтись без рестарта и не рвать keep-alive/долгие запросы.

Проверка конфига

sudo apachectl configtest

Мягкая перезагрузка

sudo apachectl graceful

Через systemd обычно так:

sudo systemctl reload apache2

На части дистрибутивов сервис называется иначе:

sudo systemctl reload httpd

Проверка после graceful

• ошибки TLS в error log (часто там сразу видно проблемы с ключом/цепочкой);
• что новый сертификат реально отдаётся (через openssl s_client);
• что сервис не ушёл в цикл перезапусков (проверьте статус systemd).

Certbot/ACME: как встроить canary и reload в автопродление

Самая частая ошибка автоматизации: «получили новый сертификат и безусловно перезагрузили все фронтенды». Лучше разделять этапы:

1. выпуск/обновление;
2. проверки (пара ключ/сертификат, цепочка);
3. canary на одном узле;
4. массовая выкатка.

Если используете хуки Certbot, старайтесь не делать «жёсткий restart». Держите логику: тест конфига → reload → проверка сертификата на узле → только потом следующий узел.

Если параллельно настраиваете безопасность HTTP, полезно сверить, что заголовки HSTS/CT/прочие выставлены корректно: это отдельная плоскость, но она часто меняется рядом с TLS. См. также материал про настройку HTTP security headers в Nginx и Apache.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Откат: как вернуться на предыдущий рабочий PEM за минуты

Откат должен быть переключением на предыдущий набор файлов, а не «срочно перевыпустить ещё раз». Именно поэтому удобны симлинки или версионированные файлы.

Откат через симлинк на архивную версию

sudo ln -sfn /etc/letsencrypt/archive/example.com/fullchain2.pem /etc/ssl/local/example.com/fullchain.pem
sudo ln -sfn /etc/letsencrypt/archive/example.com/privkey2.pem /etc/ssl/local/example.com/privkey.pem
sudo nginx -t
sudo systemctl reload nginx

Для Apache вместо reload Nginx выполните apachectl graceful (после apachectl configtest).

Наблюдаемость: как доказать себе, что выкатка была без простоя

Минимальный контроль на окно выкатки:

• ошибки рукопожатия и чтения ключа/серта в error log;
• метрики ошибок на балансировщике/прокси (например, всплеск 499/502/503);
• синтетические проверки из нескольких сетей, если это часть вашей практики;
• проверка issuer и сроков (notBefore/notAfter) после reload на каждом узле.

Если вы одновременно меняете и сертификат, и настройки TLS (шифры, ALPN, OCSP stapling), разделяйте изменения. Тогда при инциденте будет понятно, что именно сломало клиентов.

Чек-лист: PEM-rotation и TLS rollout без сюрпризов

1. Не правим боевые PEM «на месте»: используем атомарную подмену (симлинки или mv).
2. Проверяем пару ключ/сертификат.
3. Проверяем цепочку (chain.pem/fullchain.pem).
4. Проверяем конфиг: nginx -t или apachectl configtest.
5. Canary: один узел или отдельный vhost/порт.
6. Reload: systemctl reload nginx или apachectl graceful.
7. Проверяем выдачу сертификата через openssl s_client на конкретном узле.
8. Наблюдаем логи/метрики на окне выкатки.
9. Раскатываем на остальные узлы.
10. Держим быстрый откат на предыдущую версию.

Когда имеет смысл платный сертификат

Let’s Encrypt закрывает большинство задач, но иногда требования бизнеса или комплаенса требуют сертификат с формальной поддержкой или иной политикой выпуска. При этом ваша техника выкатки не меняется: всё так же важны атомарная ротация, canary и быстрый откат. Если нужен сертификат под такие требования, посмотрите SSL-сертификаты с поддержкой и предсказуемыми сроками выпуска.