SSL-сертификат для сайта: виды, как получить бесплатно и настроить на сервере

С 15 марта 2026 года максимальный срок жизни публично доверенного TLS-сертификата составляет 200 дней вместо прежних 398, с 15 марта 2027 года он сократится до 100 дней, а с 15 марта 2029 года — до 47. Ещё недавно «протухший сертификат» был редкой аварией раз в год, которую запоминали надолго. При сроке в полтора месяца это рутинная операция, и любой ручной шаг в ней рано или поздно пропустят.

Отдельная путаница связана с названием. Протокол SSL закрыт больше десяти лет назад, весь современный трафик идёт по TLS, но в поисковых запросах, прайсах удостоверяющих центров и разговорах администраторов закрепилось слово «SSL». Дальше мы пользуемся привычным термином, а в конфигурации сервера включаем TLS 1.2 и TLS 1.3.

Разберём по порядку: что меняется у сайта после перехода на HTTPS, чем DV отличается от OV и EV, как выпустить бесплатный сертификат Let's Encrypt через Certbot, какие параметры прописать в Nginx и Apache и что делать с типичными ошибками браузера

Зачем нужен SSL-сертификат для сайта

Без HTTPS с сайтом происходят неприятные вещи.

Браузер. Chrome 154 в октябре 2026 года включит режим «Always Use Secure Connections» по умолчанию: браузер сначала пробует HTTPS, а перед загрузкой публичного HTTP-сайта показывает предупреждение и просит подтверждение. Промежуточный шаг уже пройден — в Chrome 147 (апрель 2026) режим включён для пользователей Enhanced Safe Browsing. Локальных и интранет-адресов правило не касается: для 192.168.x.x и имён без точки предупреждения не будет. Про часто посещаемые сайты браузер тоже не спрашивает повторно — предупреждение адресовано новым и редким адресам.

Поиск. Google объявил HTTPS сигналом ранжирования 6 августа 2014 года и в том же анонсе описал его вес дословно: «a very lightweight signal», затрагивающий менее 1% глобальных запросов и весящий меньше, чем качество контента. Яндекс в посте для вебмастеров 2019 года формулирует ещё осторожнее: HTTPS для него — знак качества сайта, который поисковик старается учитывать, а отметку видно в Вебмастере в разделе «Качество сайта». Ни один из двух поисковиков не обещает роста позиций за сам факт перехода — практический смысл HTTPS для поиска другой: без него часть сценариев отвалится раньше, чем дело дойдёт до ранжирования.

Платежи и регуляторика. Стандарт PCI DSS запрещает SSL и ранние версии TLS как средство защиты: под «ранним TLS» PCI SSC понимает любую версию, уязвимую к известному эксплойту, поэтому практической нижней планкой оказывается TLS 1.2. Конкретную версию стандарт не называет, он требует стойкой криптографии. Узкое исключение сделано только для POS/POI-терминалов, про которые подтверждено, что они не подвержены известным эксплойтам, и для точек их терминации. На практике это значит, что интернет-магазин без HTTPS не подключат к эквайрингу

Как устроено TLS-рукопожатие

Схема ниже упрощена: она показывает порядок сообщений и число полных обменов, но не все поля протокола.

Старые схемы вроде «рукопожатие в три шага, сервер отдаёт публичный ключ» вводят в заблуждение сразу дважды. Отдельного сообщения с публичным ключом нет — ключ лежит внутри сертификата, который сервер и предъявляет. Кроме того, такое описание соответствует обмену ключами по RSA, а в TLS 1.3 он удалён вместе с остальными устаревшими наборами шифров: forward secrecy (прямая секретность) обязательна, поэтому кража приватного ключа сервера не расшифровывает трафик, записанный раньше.

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

Виды SSL-сертификатов: как выбрать подходящий

Уровень валидации отвечает на вопрос, что удостоверяющий центр проверил перед выпуском.

• DV (Domain Validation) — проверяется только контроль над доменом: положить файл по определённому пути или создать TXT-запись. Выпуск занимает минуты и полностью автоматизирован. Let's Encrypt выдаёт исключительно DV.
• OV (Organization Validation) — дополнительно проверяются юридические данные организации по реестрам и открытым источникам. Выпуск занимает рабочие дни, данные компании попадают в сертификат.
• EV (Extended Validation) — расширенная проверка организации по отдельным правилам EV Guidelines CA/Browser Forum, самая долгая и дорогая процедура.

Раньше EV делал строку с сайтом в адресной строке зеленой, но больше этого нет: Chrome убрал её в версии 77, Firefox — в версии 70, обе в 2019 году . Информация о типе валидации переехала в панель сведений о сайте, куда обычный посетитель не заглядывает. Поэтому покупать EV, чтобы клиент видел зелёную строку, больше не нужно. Остаётся только комплаенс — когда расширенную валидацию требует отраслевой регламент или служба безопасности контрагента.

Отдельно расскажем про самоподписанный сертификат. Его выпускают локально через openssl, он бесплатен и работает мгновенно, но ни в одном хранилище доверия его нет, поэтому браузер покажет NET::ERR_CERT_AUTHORITY_INVALID. Такой сертификат хорош для внутренних стендов, разработки и служебных интерфейсов, куда ходят только свои. Публичный сайт с самоподписанным сертификатом пользователь воспринимает как небезопасный.

Сколько живёт сертификат: от 398 дней к 47

В апреле 2025 года CA/Browser Forum принял ballot SC-081v3 — расписание сокращения максимального срока действия публично доверенных TLS-сертификатов. Голосование было единогласным, за проголосовали в том числе Apple, Google, Mozilla и Microsoft.

С той же даты, 15 марта 2026 года, сокращён и срок повторного использования сведений об организации для OV и EV — с 825 до 398 дней. Обязательную DNSSEC-валидацию до корневого якоря IANA при проверке контроля над доменом ввело другое решение CA/Browser Forum — ballot SC-085v2, вступивший в силу 15 марта 2026 года.

Пока сертификат жил год, ручное продление оставалось рабочей практикой: календарное напоминание, полчаса работы, забыли до следующего года. При сроке 200 дней таких работ становится две в год, при 100 днях — четыре, при 47 днях — восемь на каждый домен. Сокращается и срок повторного использования результатов проверки домена, то есть подтверждать контроль над доменом тоже придётся чаще. Поэтому вопрос «какой сертификат купить» на этом фоне вторичен — первичен вопрос, как устроено продление и что произойдёт, если оно не сработает в три часа ночи.

Охват доменов: Single, Wildcard и SAN

Single-сертификат покрывает одно имя, обычно вместе с вариантом www: example.ru и www.example.ru.

Wildcard (сертификат на маску поддоменов) выписывается на маску вида .example.ru и подчиняется двум жёстким правилам: звёздочка допустима только в крайней левой позиции и покрывает ровно один уровень имён. То есть .example.ru закрывает api.example.ru и shop.example.ru, но не закрывает dev.api.example.ru. Конструкцию ..example.ru не выдаёт ни один публичный удостоверяющий центр: для вложенного уровня нужен отдельный wildcard *.api.example.ru либо перечисление конкретных имён в поле SAN (Subject Alternative Name, поле сертификата со списком доменных имён).

Multi-domain, он же SAN, собирает несколько несвязанных имён в один сертификат: example.ru, example.com, shop.example.kz. Типовой потолок — до 100 имён, но конкретный лимит задаёт удостоверяющий центр, и у разных центров он отличается.

Конкретные суммы зависят от удостоверяющего центра и реселлера и меняются вместе с их прайсами, поэтому в таблице указан порядок величин, а точную цену смотрите у выбранного УЦ на дату покупки.

Как получить бесплатный SSL-сертификат для сайта: Let's Encrypt и Certbot

Кто стоит за Let's Encrypt

Удостоверяющий центр работает под управлением некоммерческой организации ISRG (Internet Security Research Group). Центр финансируют спонсоры по уровням: Diamond (Google и AWS), Platinum (Mozilla и EFF), Gold (Cisco, IBM, SAP и Shopify) . Сертификаты выпускаются автоматически по протоколу ACME (Automatic Certificate Management Environment), без менеджеров и счетов, и только уровня DV.

Let's Encrypt обслуживал 762 млн сайтов на конец 2025 года и выдал больше 7 млрд сертификатов за десять лет. Такой масштаб объясняет, почему корневому сертификату ISRG доверяют браузеры, мобильные платформы и системные хранилища без ручных настроек.

Текущий срок сертификата Let's Encrypt — 90 дней, и центр движется к сокращению быстрее, чем требует отраслевой график:

• с 15 января 2026 года в общий доступ (general availability) вышли профиль коротких сертификатов на 6 дней (точнее, 160 часов) и сертификаты на IP-адрес; профиль включается по запросу и дефолтным становиться не планирует;
• с 10 февраля 2027 года классический профиль переходит на 64 дня, а срок повторного использования авторизации сокращается до 10 дней;
• с 16 февраля 2028 года классический профиль переходит на 45 дней.

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

Установка Certbot и выпуск сертификата

Официальная инструкция на certbot.eff.org рекомендует большинству пользователей ставить Certbot из snap — этот пакет отслеживает релизы основного проекта (upstream) . Пакет из apt тоже рабочий: в Ubuntu 24.04 LTS это Certbot 2.9.0 с плагином python3-certbot-nginx из репозитория universe . Пакет дистрибутива получает обновления безопасности штатным механизмом и не требует snapd. Важно выбрать что-то одно: две параллельные установки создают два таймера продления поверх одного каталога /etc/letsencrypt и начинают мешать друг другу.

text

# Пакет дистрибутива, Ubuntu 24.04 LTS
sudo apt update
sudo apt install certbot python3-certbot-nginx

Перед выпуском убедитесь, что домен уже указывает A-записью на сервер и что порт 80 открыт — проверка HTTP-01 обращается к сайту снаружи.

text

sudo certbot --nginx -d example.ru -d www.example.ru

Certbot подтвердит контроль над доменом, получит сертификат, пропишет пути в конфигурацию Nginx и предложит настроить редирект с HTTP на HTTPS. Файлы окажутся в каталоге /etc/letsencrypt/live/example.ru/: fullchain.pem — сертификат сайта вместе с промежуточными, privkey.pem — приватный ключ. Именно эта пара понадобится дальше в конфигурации сервера.

Автопродление: таймер уже установлен

Пакет Certbot ставит systemd-таймер certbot.timer, который запускает certbot renew дважды в сутки . Продление срабатывает по остатку срока — когда до конца действия сертификата остаётся меньше 30 дней . Добавлять ничего не нужно, достаточно проверить, что механизм жив:

text

sudo systemctl status certbot.timer
sudo certbot renew --dry-run

Первая команда покажет, активен ли таймер и когда следующий запуск. Вторая проведёт продление вхолостую, не расходуя боевые лимиты удостоверяющего центра: если она отработала без ошибок, реальное продление тоже пройдёт. Эти две команды стоит внести в чек-лист приёмки сервера наравне с проверкой бэкапов.

Совет «добавьте задание в cron», который кочует по старым руководствам, сегодня вреден: cron-задача поверх работающего таймера даёт два конкурирующих механизма продления на одном каталоге. Cron нужен только там, где systemd нет, и в этом случае он ставится вместо таймера, а не вместе с ним:

text

# Только для систем без systemd — вместо certbot.timer, не вдобавок к нему
0 3,15 * * * /usr/bin/certbot renew --quiet

Wildcard бесплатно: проверка DNS-01

Let's Encrypt поддерживает три типа проверки: HTTP-01 (файл по пути /.well-known/acme-challenge/<токен>), DNS-01 (TXT-запись _acme-challenge.example.ru) и TLS-ALPN-01. Wildcard-сертификат выпускается только через DNS-01, двумя другими способами его получить нельзя.

text

sudo certbot certonly \
  --manual \
  --preferred-challenges dns \
  -d "*.example.ru" -d example.ru

В ручном режиме Certbot попросит создать TXT-запись и дождаться её распространения. Для автоматического продления wildcard нужен плагин вашего DNS-провайдера — без него запись придётся править руками каждые несколько недель, а это ровно тот сценарий, от которого мы уходим.

Платные SSL: когда бесплатного недостаточно

Ситуаций две, и wildcard в их число не входит: Let's Encrypt выдаёт wildcard бесплатно через DNS-01, платить за охват поддоменов не нужно.

Нужен OV или EV. Let's Encrypt выпускает только DV: подтверждает контроль над доменом и ничего не сообщает о юридическом лице. Если банк, страховая компания или государственная информационная система обязаны показывать проверенные данные организации в сертификате, DV не подойдёт — нужен коммерческий удостоверяющий центр с процедурой проверки компании.

Нужны договорные гарантии. Коммерческий центр продаёт вместе с сертификатом SLA (соглашение об уровне обслуживания) на выпуск и перевыпуск, поддержку с ответственным контактом и финансовую гарантию на случай ошибочного выпуска. Let's Encrypt работает по модели best effort (обслуживание без гарантий): договора, по которому можно предъявить претензию, с ним нет. Для большинства сайтов это несущественно, для регулируемых отраслей — аргумент.

Как установить SSL-сертификат для сайта на сервере

Nginx: конфигурация и редирект

Отправная точка при выборе параметров — Mozilla SSL Configuration Generator, профиль intermediate: он рекомендован как дефолт для публичных сайтов и балансирует безопасность с совместимостью.

text

server {
    listen 80;
    server_name example.ru www.example.ru;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name example.ru www.example.ru;

    ssl_certificate     /etc/letsencrypt/live/example.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.ru/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
    ssl_prefer_server_ciphers off;

    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:10m;

    add_header Strict-Transport-Security "max-age=63072000" always;

    root /var/www/example.ru;
}

Четыре частых ошибки:

• В ssl_certificate указывается fullchain.pem, а не cert.pem. Первый файл содержит и сертификат сайта, и промежуточные, без которых цепочка доверия не выстроится у части клиентов — подмена именно этих двух файлов даёт самую частую ошибку неполной цепочки.
• В ssl_certificate_key идёт privkey.pem из того же каталога.
• ssl_prefer_server_ciphers off — в профиле intermediate приоритет отдан выбору клиента, это осознанное решение Mozilla, а не упущение.
• Набор HIGH:!aNULL:!MD5, до сих пор кочующий по руководствам, не гарантирует forward secrecy: он пропускает статический обмен ключами по RSA и допускает режимы CBC. Меняйте его на явный список выше.

Список ssl_ciphers в конфигурации выше сокращён: в нём оставлены только наборы ECDHE из профиля intermediate. Полный профиль Mozilla включает ещё варианты DHE-RSA и параметр ssl_dhparam. Сгенерировать его целиком можно на ssl-config.mozilla.org.

Заголовок HSTS (HTTP Strict Transport Security) включайте, когда убедились, что весь сайт и все нужные поддомены работают по HTTPS: политика запоминается браузером на срок max-age, и быстро откатить её не получится.

text

sudo nginx -t
sudo systemctl reload nginx

OCSP stapling с Let's Encrypt больше не работает

OCSP расшифровывается как Online Certificate Status Protocol, протокол проверки статуса сертификата. Stapling значит, что свежий ответ о статусе сервер прикладывает к соединению сам. Строки ssl_stapling on; ssl_stapling_verify on; годами кочуют из конфигурации в конфигурацию, но в связке с сертификатом Let's Encrypt сегодня ничего не делают — сшивать нечего.

Информация об отзыве публикуется теперь только через CRL . Причина в приватности: OCSP-респондер видел, какой сайт запрашивает конкретный клиент, то есть работал как канал утечки истории посещений. Для сертификатов коммерческих удостоверяющих центров с живым OCSP смысл в stapling сохраняется, а в конфигурации под Let's Encrypt эти две строки можно убрать, чтобы они не создавали ложного впечатления работающей проверки отзыва.

Apache: mod_ssl

text

<VirtualHost *:443>
    ServerName example.ru
    DocumentRoot /var/www/example.ru

    SSLEngine on
    SSLCertificateFile    /etc/letsencrypt/live/example.ru/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.ru/privkey.pem

    SSLProtocol -all +TLSv1.2 +TLSv1.3
    SSLHonorCipherOrder off
</VirtualHost>

<VirtualHost *:80>
    ServerName example.ru
    Redirect permanent / https://example.ru/
</VirtualHost>

Директива SSLCertificateChainFile объявлена устаревшей с Apache 2.4.8 и встречается в руководствах до сих пор. Отдельный файл цепочки сегодня не нужен: промежуточные сертификаты кладутся в тот же файл, который указан в SSLCertificateFile, то есть в fullchain.pem . Если вы копируете конфигурацию из старой статьи и видите там третий путь к файлу цепочки — это признак того, что материал устарел и остальные параметры в нём тоже стоит перепроверить.

Проверка после установки

text

curl -I https://example.ru
openssl s_client -connect example.ru:443 -servername example.ru -showcerts

curl -I показывает код ответа и заголовки, в том числе Strict-Transport-Security — так проверяется и редирект, и HSTS. openssl s_client выводит всю предъявленную сервером цепочку и параметры соединения. Флаг -servername обязателен, если на одном IP живёт несколько сайтов, иначе вы получите сертификат сайта по умолчанию и потратите час на несуществующую проблему. Внешняя проверка — SSL Labs Server Test на ssllabs.com/ssltest, целевой рейтинг A или A+, там же диагностируются проблемы цепочки.

Дальше начинается обычная эксплуатация сервера, на котором теперь работает HTTPS: резервное копирование, вынос базы в управляемый сервис, автоматизация выкладки.

Куда поставить сертификат в облаке

Собственного удостоверяющего центра у VK Cloud нет: платформа не выдаёт DV-, OV- и EV-сертификаты от своего имени. Часть шагов автоматизирована: CDN (сеть доставки контента), например, сама получает бесплатный Let's Encrypt. Для веб-сайта сертификат применяется в нескольких точках платформы, и у каждой свой порядок действий.

• Балансировщик нагрузки. В правиле балансировки с протоколом TERMINATED_HTTPS появляется параметр «Сертификат»: балансировщик терминирует TLS на себе, а до бэкендов трафик идёт внутри приватной сети. Сертификат загружается новым или выбирается из загруженных ранее.
• CDN. При создании CDN-ресурса в блоке настроек шифрования по умолчанию выбран бесплатный Let's Encrypt. Сертификат выпускается после того, как доступны серверы-источники и в DNS распространились изменения CNAME-записей: обычно на это уходит до 30 минут. Свой сертификат добавляется в хранилище сертификатов (раздел «Управление SSL-сертификатами» в CDN) и затем выбирается в настройках шифрования ресурса.
• Managed Kubernetes. Сертификат подключается в Ingress: можно загрузить существующий. Установку cert-manager через Helm 3 документация VK Cloud описывает отдельной инструкцией, а автоматический выпуск сертификатов дальше обеспечивает сам cert-manager. Логика та же, что у остальной автоматизации кластера, например у выкладки через Argo CD.
• Отдельная виртуальная машина. Здесь всё как на своём железе: Certbot, Nginx или Apache, systemd-таймер продления.

Если сайт разворачивается с нуля, порядок такой: поднять сайт на облачном сервере, направить на него домен, а затем либо выпустить сертификат Certbot прямо на машине, либо терминировать HTTPS на балансировщике и не держать приватные ключи на каждом бэкенде. Состав сервисов и тарифы — на сайте VK Cloud.

Типичные ошибки и как их исправить

В случае со смешанным контентом поведение браузеров изменилось. С Chrome 80 (январь 2020 года) аудио и видео, запрошенные по HTTP на HTTPS-странице, браузер автоматически повышает до HTTPS, а если по HTTPS ресурс не отдаётся, он просто не загрузится. Изображения в Chrome 80 ещё грузились, но помечали страницу как небезопасную («Not Secure»); их автоматическое повышение включили следом, и сегодня Chrome так же повышает HTTP-изображения до HTTPS, а при неудаче не загружает их. Скрипты, iframe и XHR (XMLHttpRequest) браузер относит к блокируемому смешанному контенту (blockable mixed content) и блокирует, не пытаясь повысить протокол . Протокол-относительные ссылки вида //example.ru/script.js — приём эпохи, когда сайт жил одновременно на HTTP и HTTPS, сегодня это антипаттерн, пишите полный https://.

Отдельно про совет «добавьте директиву ssl_certificate_chain», который встречается в старых инструкциях: такой директивы в Nginx нет. Промежуточные сертификаты живут в fullchain.pem, и правильное исправление неполной цепочки — заменить путь к файлу, а не искать несуществующий параметр.

Заключение

Технически подключить HTTPS сегодня — работа на десять минут: Certbot выпустит сертификат, пропишет пути в конфигурацию и включит редирект. Дальше начинается эксплуатация, и именно она определяет, ляжет сайт ночью или нет. Проверьте три вещи: активен ли certbot.timer, проходит ли certbot renew --dry-run без ошибок, есть ли уведомление на случай, если продление не сработало. Если все три ответа «да», к задаче можно не возвращаться до следующего переезда. К 2029 году отрасль придёт к 47 дням, и запаса на ручные операции не останется. Правильный SSL-сертификат для сайта — не тот, который дороже, а тот, который продлевается сам.