Зачем вообще мигрировать с Let's Encrypt на коммерческий DV
Let's Encrypt закрыл огромный пласт задач, но есть случаи, когда коммерческий DV оказывается предпочтительнее. Чаще всего это требования тендера или заказчика (формальный вендор, SLA и поддержка), расширенная совместимость со старыми или встроенными клиентами (в том числе IoT/SDK), централизованная закупка SAN-пакетов под десятки доменов, или желание уменьшить частоту перевыпусков (90 дней у LE против ежегодного у коммерческих DV). Иногда решающими становятся альтернативные методы DCV и более гибкие цепочки сертификации.
Ключевой риск миграции — потерять часть клиентов на старых девайсах, собрать некорректную цепочку сертификатов или не настроить автоматическое обновление. Ниже — пошагово о том, как пройти этот путь аккуратно. Если вы берёте коммерческий DV у провайдера, заранее уточните доступность ACME и варианты цепочек. У нас доступны коммерческие SSL-сертификаты, в том числе с SAN.
Термины: DV, SAN, цепочка сертификатов, ACME
DV — доменная валидация. Быстрая выдача, минимальная бюрократия, но строгие технические требования к подтверждению домена (DCV: HTTP-01, DNS-01, TLS-ALPN-01 или e-mail к админ-контактам). SAN (Subject Alternative Name) — поле, через которое один сертификат покрывает несколько имён: example.com, www.example.com, api.example.com и пр. Цепочка сертификатов — последовательность «сертификат сайта → промежуточные → корневой», по которой клиент строит доверие. ACME — протокол автоматической выдачи/продления сертификатов (не только Let's Encrypt; многие коммерческие CA уже поддерживают ACME или собственный API).
Инвентаризация: какие имена уедут в один SAN
Сначала составьте полный список FQDN, обслуживаемых фронтами и бекендами. Разделите сертификаты по зонам ответственности и рискам:
- Веб-слой: основной домен, www, статический CDN-источник, субдомены API.
- Сервисные порты: SMTP/IMAP/POP3 для почты, gRPC, брокеры, admin-панели, внутренние endpoints под VPN.
- Границы ответственности: не мешайте в один SAN разные команды и разные циклы релизов. Чем больше имён в одном сертификате, тем больше «зона отказа» при неполадке.
Проверьте, что любое имя, для которого вы раньше выдавали отдельный сертификат LE, теперь либо входит в SAN, либо получит отдельный DV. Уточните, не нужны ли подстановочные имена: *.example.com покрывает только один уровень поддоменов и не заменяет example.com — голое имя надо добавлять отдельно. Для планирования wildcard-сценариев пригодится материал «Wildcard и DNS-01: автоматизация», см. статью Wildcard + DNS-01: автоматизация выпуска.
Алгоритмы и ключи: RSA, ECDSA и «дуальная» подача
Базовый выбор: RSA 2048 как «lowest common denominator» или ECDSA P-256 для экономии CPU и меньшего размера рукопожатий. На фронтах с высокой нагрузкой и современной аудиторией разумна «дуальная» подача: одновременно ECDSA и RSA — сервер сам выберет лучшее по возможностям клиента. Так вы не потеряете старых клиентов, а новые получат выигрыш в производительности.
Рекомендации из практики:
- RSA минимум 2048, лучше 3072 для консервативных сред.
- ECSDA secp256r1 (P-256) как дефолт; P-384 — по необходимости.
- Разделяйте приватные ключи и права доступа; для ECDSA и RSA используйте разные файлы и чёткую ротацию.
CSR и DCV: подготовка к выпуску
Для коммерческого DV готовим CSR на весь набор SAN. Решите, будете ли вы переиспользовать существующий ключ или сгенерируете новый (рекомендуется ротация при смене CA). DCV лучше автоматизировать:
- HTTP-01 — через webroot/alias на фронте; хорош для большого числа имён, если они сходятся на одну или несколько точек публикации.
- DNS-01 — универсален для wildcard и когда HTTP недоступен; потребует API-доступ к DNS или аккуратной полуавтоматической рутины.
- TLS-ALPN-01 — полезен, когда HTTP-слой закрыт, но контроль TLS на 443 есть.
- E-mail DCV — как запасной вариант, но плохо автоматизируется и не подходит под массовые SAN.
Проверьте, поддерживает ли выбранный CA ACME. Если да — модель и пайплайн близки к текущему LE. Если нет — изучите их API или агента. Важно: ещё на стадии заказа уточнить состав цепочки (intermediate), чтобы потом не ловить сюрпризы совместимости. Если вы переносите крупный SAN после LE и упирались в лимиты, загляните в обзор про стратегии, см. SAN и лимиты Let's Encrypt: автоматизация.
Цепочки: fullchain, порядок и кросс-подписи
На практике чаще всего ломается не сам сертификат, а цепочка. Важно соблюсти три пункта:
- Правильный файл для сервера. Для Nginx — «сертификат сайта + промежуточные» (часто называемый fullchain). Корневой добавлять не нужно. Для Apache 2.4.8+ также достаточно одного файла с полным набором без корневого.
- Порядок. Сначала сертификат сайта, затем промежуточные в правильной последовательности. Перепутанный порядок ломает валидацию у части клиентов.
- Кросс-подписанные корни. Некоторые CA выдают цепочки, которые строятся по-разному в зависимости от доверенного набора на клиенте. Если ваша аудитория включает старые Android/Java, заранее проверьте, какая цепочка будет выдана и как она строится на реальных клиентах.
Из практики хорошо себя показывает включение OCSP stapling и контроль того, что промежуточный сертификат доступен локально, чтобы не было сетевой зависимости от AIA-загрузки у клиента.
Настройка на сервере: Nginx и Apache
Пример Nginx c дуальной подачей ECDSA+RSA и включённым stapling:
server {
listen 443 ssl http2;
server_name example.com www.example.com;
# ECDSA
ssl_certificate /etc/ssl/example.com/ecdsa/fullchain.pem;
ssl_certificate_key /etc/ssl/example.com/ecdsa/privkey.pem;
# RSA
ssl_certificate /etc/ssl/example.com/rsa/fullchain.pem;
ssl_certificate_key /etc/ssl/example.com/rsa/privkey.pem;
ssl_trusted_certificate /etc/ssl/example.com/chain.pem;
ssl_stapling on;
ssl_stapling_verify on;
# Остальная конфигурация...
}
Для Apache 2.4.8+:
<VirtualHost *:443>
ServerName example.com
ServerAlias www.example.com
SSLEngine on
SSLCertificateFile /etc/ssl/example.com/fullchain.pem
SSLCertificateKeyFile /etc/ssl/example.com/privkey.pem
# При необходимости: SSLCACertificateFile для цепочки, если не используется fullchain
# Остальная конфигурация...
</VirtualHost>
Проверьте, что путь ssl_trusted_certificate в Nginx указывает на файл, содержащий цепочку, используемую для OCSP-валидации (обычно промежуточные). Не подсовывайте туда корневой без необходимости.
Переезд без простоя: параллельная установка и проверка
Лучший способ — поставить коммерческий DV рядом с действующим LE и проверить SNI-ответ на тестовом домене или на отдельном listen/порте, не затрагивая прод. Затем переключить на боевом виртуальном хосте. На собственном VDS проще организовать параллельные listen и быстрые откаты.
Быстрые проверки перед релизом:
- Состояние цепочки и OCSP stapling.
- Совместимость с ECDSA- и RSA-клиентами.
- Наличие всех SAN-имён и корректность Common Name.
Команды для локальной валидации:
openssl s_client -connect example.com:443 -servername example.com -showcerts
openssl s_client -connect example.com:443 -servername example.com -status
openssl verify -CAfile /etc/ssl/example.com/chain.pem /etc/ssl/example.com/cert.pem
Соберите отчёт по рукопожатию: версии TLS, наборы шифров, какой именно сертификат отдан (RSA или ECDSA), как выглядит цепочка.
Автоматизация обновления: ACME, API и systemd
Если у CA есть ACME-эндпоинт, вы почти полностью повторяете текущий процесс. Два популярных пути — certbot и acme.sh. Схема с certbot:
certbot certonly --server https://acme.vendor.tld/directory --agree-tos -m admin@example.com --dns-provider dns_cf -d example.com -d www.example.com -d api.example.com
systemctl reload nginx
Пример с acme.sh:
acme.sh --register-account -m admin@example.com --server https://acme.vendor.tld/directory
acme.sh --issue --dns dns_cf -d example.com -d www.example.com --server https://acme.vendor.tld/directory
acme.sh --install-cert -d example.com --fullchain-file /etc/ssl/example.com/fullchain.pem --key-file /etc/ssl/example.com/privkey.pem --reloadcmd "systemctl reload nginx"
У некоторых CA нет ACME, но есть API/агент. Тогда строим свой обновлятор: скрипт «за N дней до истечения» вызывает выпуск/перевыпуск, кладёт файлы на место и делает reload. Под systemd это выглядит аккуратно:
[Unit]
Description=Renew commercial DV certs
After=network-online.target
Wants=network-online.target
[Service]
Type=oneshot
ExecStart=/usr/local/bin/renew-dv-certs.sh
[Install]
WantedBy=multi-user.target
[Unit]
Description=Daily check for DV certs renewal
[Timer]
Persistent=true
[Install]
WantedBy=timers.target
Внутри renew-dv-certs.sh проверьте срок действия (например, через openssl x509 -enddate), и если осталось меньше 30 дней — запускайте процедуру перевыпуска и затем systemctl reload nginx или ваш балансировщик. Обязательно закладывайте ретраи и оповещения.
Совместимость: что проверить до переключения
Минимальный набор проверок:
- Старые клиенты. Android 7/6, legacy Java, встроенные SDK. Убедитесь, что цепочка строится без внешней AIA-загрузки.
- Алгоритмы. Если включили только ECDSA, высок шанс потери части клиентов. Дуальная подача снимает риск.
- OCSP stapling. Включён, валиден, кеш прогрет. Проверяйте флаг
OCSP Response Status: successful. - TLS-версии. Отсечены устаревшие TLS 1.0/1.1, но сохранён доступ для клиентов на TLS 1.2.
Дополнительно прогоните интеграционные тесты с вашими мобильными приложениями и внешними интеграторами. Если у вас есть mTLS на внутренних шинах, убедитесь, что доверенный набор CA у клиентов включает новую цепочку.
Частые ошибки и как их избежать
- Неполная цепочка. На фронте лежит только сертификат сайта — добавляйте промежуточные.
- Перепутанный порядок. В fullchain сначала должен идти сертификат сайта, затем промежуточные по порядку.
- Забыли имя в SAN. Голый домен и www — добавляйте оба; wildcard не закрывает голое имя.
- Нет автоматизации. Оставили всё на «ручной контроль конца срока» — через год вас это подведёт.
- Нет reload. Сертификат обновили, но сервер не перезагрузили — клиенты продолжают видеть старый.
- Смешение сред. Тестовые имена в боевом SAN — увеличивают зону риска и усложняют ротации.
- IDN/пуникод. Для интернациональных доменов проверьте корректный punycode в CSR и SAN.
Отключение автоматизации Let's Encrypt
Не спешите удалять всю инфраструктуру LE. На переходный период (2–4 недели) оставьте старый планировщик, но переключите виртуальный хост на новый сертификат. Когда убедитесь, что коммерческий DV стабильно обновляется, аккуратно отключите задания LE, удалите HTTP-01 алиасы и лишние DNS-записи для DCV, почистите старые ключи.
Разделение сертификатов по сервисам
Не всегда выгодно тащить всё в один SAN. Веб — отдельно, почта — отдельно, внутренние сервисы — отдельно. Так вы уменьшите blast radius при сбоях и снизите потребность в экстренном перевыпуске большого мульти-SAN при изменениях в одном сервисе.
Безопасность: хранение ключей и ротация
Приватные ключи держите на минимально необходимом числе хостов, права 600, владелец — пользователь демона веб-сервера или root. Включите аудит доступа, не гоните ключи в репозиторий и backup без шифрования. Продумывайте план ротации при компрометации: отзыв, перевыпуск, массовый reload, контроль логов ошибок и OCSP.
Итог: надёжный план миграции
Инвентаризация имён, выбор алгоритма и SAN, уточнение цепочки у CA, тестовая выдача, параллельная установка, проверки совместимости, автоматизация обновления и мониторинг — этого достаточно, чтобы переезд прошёл без простоев и неприятных сюрпризов.
Сделайте проект миграции небольшим и повторяемым: единые шаблоны конфигурации, централизованные хуки на reload, мониторинг срока действия и OCSP, чек-лист на выпуск/обновление. Тогда коммерческий DV станет не усложнением, а предсказуемой частью вашего контура безопасности и совместимости. Если ещё выбираете инфраструктуру для размещения фронтов, посмотрите наши варианты виртуальный хостинг и VDS.
