Почему спор «Let’s Encrypt vs платный SSL» вообще возникает
В поиске часто встречается формулировка let’s encrypt vs paid ssl, и она немного путает. Let’s Encrypt — удостоверяющий центр (CA), который бесплатно выдаёт TLS-сертификаты по протоколу ACME. «Платный SSL» — сертификат коммерческого CA за деньги, зачастую с дополнительными опциями: валидация организации, поддержка, управляемые процессы, иногда финансовые гарантии.
На практике вопрос звучит так: достаточно ли вам бесплатного DV-сертификата с коротким сроком и автоматическим продлением или нужен коммерческий сертификат с OV/EV, формальными проверками и предсказуемой поддержкой.
С точки зрения криптографии «бесплатный» и «платный» сертификат могут быть одинаково сильными. Стойкость определяется не ценой, а алгоритмами, параметрами TLS на сервере и тем, как вы защищаете приватный ключ.
База: что именно проверяет сертификат (DV, OV, EV)
Запросы вроде ov dv ev — про уровень проверки личности/организации, а не про «силу шифрования».
- DV (Domain Validation) — подтверждается контроль над доменом. Этого достаточно для HTTPS и «замочка». Let’s Encrypt выдаёт именно DV.
- OV (Organization Validation) — дополнительно проверяется организация (юрлицо/ИП, адрес и т.п.). Данные организации отражаются в сертификате.
- EV (Extended Validation) — расширенная проверка (строже процедурно). В браузерах EV уже не выделяется «магически», но подтверждённые данные об организации остаются доступными в деталях сертификата.
DV решает задачу «зашифровать и подтвердить домен». OV/EV решают «привязать домен к юридической сущности» — это важно для комплаенса, тендеров, B2B и корпоративных политик.
Если вы выбираете коммерческий сертификат под OV/EV или хотите централизованно закрыть закупку/продление в компании, удобнее сразу смотреть готовые SSL-сертификаты с нужным типом проверки.
Let’s Encrypt: сильные стороны в админской реальности
Автоматизация и скорость
Let’s Encrypt идеально ложится на DevOps-подход: CI/CD, автоскейлинг, быстрое поднятие окружений, инфраструктура как код. ACME-клиенты (certbot, lego, acme.sh) выпускают и продлевают сертификаты без ручных тикетов и ожиданий.
Если у вас десятки доменов/поддоменов, микросервисы, временные стенды — автоматизация часто важнее «бумажной» части идентификации. Для практики настройки и типовых граблей полезно держать под рукой материал про выпуск и HSTS: HTTPS, Certbot и HSTS в продакшене.
Цена и операционная экономия
Ноль стоимости за выпуск — очевидный плюс. Но часто ещё важнее косвенная экономия: не нужно планировать закупки, согласовывать счета, держать «дату продления» в календарях. При нормальной автоматизации продление происходит само.
Совместимость с современными клиентами
Цепочки Let’s Encrypt широко доверяются современными браузерами и ОС. Для типовых веб-сайтов, API, админок и многих B2B-проектов DV более чем достаточно.
Слабые стороны Let’s Encrypt, которые всплывают у продакшена
Короткий срок действия и операционные риски
Let’s Encrypt выдаёт сертификаты с коротким сроком (90 дней). Это нормально, если автоматизация продления действительно работает. Но если она ломается — продакшен падает быстро и громко.
Частые причины срывов продления:
- изменился веб-сервер/роутинг, и HTTP-01 challenge перестал доходить до нужного инстанса;
- закрыли порт 80 или агрессивно редиректят HTTP, и challenge не проходит;
- ошибки DNS при DNS-01: не те права на API, неправильная зона, TTL и кеширование;
- rate limits и массовые перевыпуски «в панике»;
- сломалась интеграция в панели/оркестраторе/cron/systemd timer, а алертов нет.
В больших системах это лечится дисциплиной: мониторинг срока, тесты продления в staging, алерты, резервные сценарии. Но если администрирование «на бегу», риск выше, чем у годовых коммерческих сертификатов.
Только DV: не закрывает требования к идентификации
Если нужно формально подтверждать юридическое лицо в сертификате (OV/EV) — Let’s Encrypt не подходит. Это часто всплывает в B2B-интеграциях, тендерах и внутреннем комплаенсе, а также в корпоративных политиках прокси/MDM.
Поддержка и ответственность
У Let’s Encrypt нет классической коммерческой поддержки «по SLA в тикете». Есть документация и сообщество, но в момент инцидента бизнесу иногда важна именно ответственность и понятный регламент перевыпуска.
Платный SSL: за что платят на практике
OV/EV и документальная проверка
Ключевое отличие платного SSL — возможность выбрать OV/EV и закрыть требования к идентификации организации. Если задача — «показать, кто стоит за доменом» на уровне сертификата и процессов, коммерческий вариант обычно проще согласовать и защищать документально.
Поддержка и управляемые процессы
Коммерческие CA обычно предлагают поддержку и понятные правила перевыпуска, смены ключей, действий при компрометации, миграций. Для компаний это иногда важнее, чем «насколько быстро выпустится DV».
Меньше точек отказа вокруг продления
Хотя рынок в целом движется к сокращению сроков, в реальности платные сертификаты выбирают, когда хочется реже зависеть от автоматизации продления и снизить риск внезапного истечения там, где ACME сложно внедрить (закрытые контуры, бюрократия, ограничения по DNS/портам).
Сопутствующие продукты
У коммерческих CA есть продукты вокруг инфраструктуры доверия: wildcard, сертификаты для подписи кода, S/MIME и другие. Это уже не только про HTTPS на сайте.
Что выбрать для разных задач: практические сценарии
Сайт компании, блог, лендинг, интернет-магазин
Если нет требований по OV/EV, Let’s Encrypt обычно лучший старт: быстро, бесплатно, совместимо. Деньги чаще разумнее вложить в резервирование, мониторинг, защиту периметра и отказоустойчивость.
Платный DV имеет смысл, если вы сознательно хотите «упростить» операционку (например, реже трогать цепочки в контурах, где автоматизация даётся тяжело), но это скорее про ваши процессы и риски, чем про качество шифрования.
Личный кабинет, B2B-портал, SaaS для компаний
Здесь часто всплывают формальные требования заказчиков: «нужен OV» как часть политики. В таком случае OV становится аргументом сам по себе — даже если браузер это никак эффектно не подсветит.
API и микросервисы
Для публичного HTTPS API Let’s Encrypt обычно подходит отлично, особенно при выпуске на ingress/reverse proxy. Но если вам нужен mTLS между сервисами, публичный CA может быть лишним: часто корректнее строить внутренний PKI и раздавать сертификаты через свои механизмы. Это отдельная большая тема.
Почта (SMTP/IMAP) и совместимость клиентов
На почтовых сервисах важны стабильность цепочек доверия и правильная настройка TLS. Let’s Encrypt чаще всего работает нормально, но при большом количестве «сложных» клиентов (legacy-устройства и старый софт) иногда проще жить с коммерческими цепочками и предсказуемой поддержкой. Перед выбором полезно прогонять тесты на ваших целевых клиентах.
Критерии выбора: чек-лист без маркетинга
- Есть ли требование OV/EV? Если да — почти всегда нужен платный SSL.
- Есть ли надёжная автоматизация продления? Если инфраструктура не готова, 90 дней превращаются в риск.
- Насколько динамичен ландшафт? Чем больше доменов, стендов и частых изменений, тем сильнее выигрыш от ACME.
- Нужны ли SLA/поддержка/регламент? В критичных контурах это может быть решающим.
- Есть ли ограничения по портам/DNS? Жёсткие сети и бюрократия вокруг DNS мешают ACME-проверкам.
- Какова цена простоя? Если простой дорогой, закладывайте мониторинг истечения и аварийный план независимо от типа сертификата.
Как не поймать инцидент с истёкшим сертификатом
Независимо от типа сертификата, продакшен любит предсказуемость. Минимальный набор практик:
- Мониторинг срока действия сертификата с алертом заранее (30/14/7 дней).
- Проверка цепочки сертификатов и OCSP stapling после перевыпуска.
- Регламент экстренного перевыпуска: кто делает, где лежат доступы, как быстро выкатываем.
- Раздельное хранение ключей и доступы по принципу минимальных привилегий.
- Тестирование продления в staging (особенно для DNS-01 и балансировщиков).
Простой базовый мониторинг можно сделать без внешних сервисов, хотя бы через cron и локальную проверку даты истечения. Например, для Nginx/Apache с PEM-файлом:
openssl x509 -in /etc/ssl/certs/site.pem -noout -enddateА если сертификат проверяете по сети (важно для реальной картины на балансировщике):
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -enddateСамая дорогая часть TLS — не сертификат, а ошибки в процессах вокруг него. Цена «бумажки» меркнет на фоне простоя, если HTTPS внезапно перестал быть валидным.
Если вы планируете автоматизацию через DNS-01 и wildcard, заранее проверьте ограничения и rate limit-поведение, чтобы не упереться в лимиты на массовых перевыпусках: лимиты Let’s Encrypt и автоматизация перевыпуска.
Итог: краткая рекомендация
Если вам нужен просто HTTPS и вы готовы (или уже умеете) в автоматизацию — Let’s Encrypt закрывает задачу быстро и без затрат. Если же требуется подтверждение организации (OV/EV), нужна поддержка/регламент или таковы требования комплаенса и клиентов — платный SSL будет более подходящим инструментом.
В продакшене правильный выбор обычно не «бесплатный против платного», а «какой уровень идентификации и какой уровень операционной зрелости у нашей инфраструктуры».
