Блог ДоверьсяСервису

SSL-сертификат: как работает HTTPS и как защитить сайт

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

02.09.2026 Обновлено 02.09.2026 10 мин чтения Редакция ДоверьсяСервису

Главное: сертификат связывает доменное имя с открытым ключом, а соответствующий закрытый ключ остается у владельца сайта. Во время TLS-соединения браузер проверяет имя, срок действия, подпись и цепочку доверия, после чего стороны создают сеансовые ключи для защиты трафика.

Что защищает HTTPS

TLS создает защищенный канал между клиентом и сервером. Стандарт TLS 1.3 выделяет три базовых свойства: аутентификацию стороны, конфиденциальность передаваемых данных и целостность обмена. Для веб-сайта это означает, что постороннему в сети сложнее прочитать или незаметно изменить запросы, ответы, формы, cookie и загружаемые ресурсы.

Сертификат не шифрует базу данных на диске, не удаляет вредоносный код и не доказывает добросовестность владельца. Фишинговая страница тоже может иметь действующий сертификат. HTTPS защищает конкретное соединение с указанным доменом, а безопасность приложения, учетных записей и серверов требует отдельных мер.

Как проходит TLS-соединение

Браузер обращается к домену и сообщает поддерживаемые версии TLS и алгоритмы.
Сервер выбирает совместимые параметры и отправляет сертификат с промежуточной цепочкой.
Браузер проверяет доменное имя, даты, назначение сертификата, подписи и доверенный корень.
Сервер доказывает владение закрытым ключом, подписывая данные рукопожатия.
Стороны получают общие сеансовые ключи, не передавая их как обычный открытый текст.
HTTP-запросы и ответы идут внутри защищенных TLS-записей.

Сертификат проверяет подлинность сервера, а основной трафик защищают быстрые симметричные ключи, созданные на время соединения. Закрытый ключ не шифрует каждую страницу.

Что находится внутри сертификата

Поле	Что показывает	Что проверить
SAN	Домены, для которых выдан сертификат	Есть ли нужный хост, включая www
Субъект	Сведения о владельце в пределах типа проверки	Не путать с гарантией надежности сайта
Издатель	Удостоверяющий центр или промежуточный центр	Строится ли доверенная цепочка
Срок	Начало и окончание действия	Корректны ли часы и настроено ли продление
Открытый ключ	Публичная часть ключевой пары	Совместим ли алгоритм с сервером и клиентами
Назначение	Разрешенные способы использования ключа	Допускается ли аутентификация сервера
Подпись	Подтверждение издателя	Принимает ли ее доверенная цепочка клиента

Закрытого ключа в сертификате нет. Он хранится на сервере или в защищенном хранилище. При раскрытии ключа сертификат заменяют, старый отзывают, причину утечки устраняют, а журналы проверяют.

Как браузер строит цепочку доверия

Обычно сервер отправляет конечный сертификат сайта и один или несколько промежуточных сертификатов. Браузер проверяет их подписи до корневого центра, которому доверяет его операционная система или собственное хранилище. Корневой сертификат серверу обычно передавать не требуется.

Частая ошибка — забыть промежуточный сертификат. У администратора страница может открыться благодаря кэшу, а у нового клиента проверка завершится ошибкой. Тестируйте с чистого клиента и с передачей имени через SNI.

DV, OV и EV: в чем разница

Тип	Что проверяет центр	Когда уместен
DV	Контроль над доменным именем	Блоги, лендинги, магазины и большинство публичных сайтов
OV	Домен и сведения об организации	Когда проверенная организация нужна процессам или политике
EV	Расширенный набор организационных проверок	Когда это прямо требуется корпоративными правилами

Уровень проверки владельца не равен силе шифрования. DV, OV и EV могут использовать сопоставимые ключи и параметры TLS. Современный интерфейс браузера также не обещает заметно выделять EV. Выбирать дорогой вариант только ради предполагаемого «зеленого адреса» не стоит: сначала определите юридическое и эксплуатационное требование.

Для обычного проекта DV часто достаточно. В категории бесплатных SSL-сертификатов можно изучить варианты выдачи, но перед выбором важно сравнить не только цену, а автоматическое продление, поддержку DNS-проверки, экспорт ключа и ответственность за установку.

Один домен, SAN и wildcard

Однодоменный сертификат охватывает конкретный набор имен, указанный при выпуске. SAN-сертификат содержит несколько имен, например основной домен, www и отдельный API. Wildcard с маской вида *.example.com удобен для одноуровневых поддоменов, но обычно не покрывает сам example.com и более глубокое имя вида a.b.example.com, если они не добавлены отдельно.

Wildcard упрощает управление, но увеличивает последствия утечки одного закрытого ключа: им могут пользоваться несколько узлов. Для независимых систем безопаснее отдельные сертификаты и ключи. SAN удобен для тесно связанных имен, однако его перевыпуск может затронуть весь набор, а список имен виден в сертификате и журналах прозрачности.

Бесплатный и платный сертификат

Оплата не делает криптографию сильнее. Платные предложения могут включать организационную проверку, поддержку, договорные условия и управление. Сравнивайте полный процесс эксплуатации.

поддерживается ли нужный тип проверки и набор доменов;
есть ли ACME или другой механизм автоматизации;
поддерживаются ли HTTP-, DNS-проверка и экспорт ключа;
как быстро выполняются выпуск, перевыпуск и отзыв;
кто получает уведомления и отвечает на сбой продления;
есть ли ограничения панели, CDN, балансировщика или хостинга.

Карточка nic.ru показывает пример провайдера доменных услуг. Уточните, устанавливает ли панель сертификат автоматически, где завершается TLS и защищен ли путь до исходного сервера.

Где завершается TLS

HTTPS может завершаться не на веб-сервере, а на CDN, reverse proxy, балансировщике или облачном шлюзе. Дальше запрос иногда идет к исходному серверу по новому TLS-соединению или без него. Посетитель видит защищенный внешний участок, но это не подтверждает защиту внутреннего маршрута.

Нарисуйте путь запроса: браузер → CDN → балансировщик → приложение. Для каждого участка укажите протокол, имя в сертификате, способ проверки исходного узла и владельца продления. Карточка Cloudflare иллюстрирует сервис с пограничным проксированием: сертификат на внешнем контуре не отменяет необходимость корректно проверять сертификат origin-сервера.

Как получить сертификат

Составьте список всех публичных имен: основной домен, www, API, почтовые и технические поддомены.
Определите точки завершения TLS и владельца каждой конфигурации.
Выберите DV, OV или EV и форму покрытия имен.
Создайте ключевую пару в контролируемой среде и подготовьте запрос, если этого требует поставщик.
Подтвердите контроль домена через DNS, HTTP или другой разрешенный метод.
Установите конечный сертификат, промежуточную цепочку и закрытый ключ.
Проверьте имя, цепочку, версии протокола и доступ с разных клиентов.
Настройте автоматическое продление, мониторинг срока и проверку после замены.

ACME уменьшает ручные операции, но автоматизация должна охватывать проверку домена, выпуск, доставку, размещение ключа, reload службы и внешний контроль результата.

План перехода сайта на HTTPS

Сделайте резервную копию конфигурации и снимите текущие метрики.
Поднимите HTTPS параллельно HTTP и проверьте все шаблоны и формы.
Замените абсолютные HTTP-ссылки на стили, скрипты, изображения, шрифты и API.
Обновите canonical, hreflang, Open Graph, карту сайта и адреса интеграций.
Настройте один постоянный редирект с каждой HTTP-страницы на соответствующий HTTPS-адрес без цепочек.
Проверьте robots.txt, sitemap, счетчики, вебхуки, платежи и внешние обратные вызовы.
Проследите за обходом, ошибками, индексированием и органическим трафиком.
Включайте HSTS только после стабильной работы всех нужных поддоменов.

Mixed content возникает, когда HTTPS-страница загружает ресурс по HTTP. Браузер обновит или заблокирует запрос, поэтому все зависимости нужно перевести на HTTPS.

HSTS: применять осторожно

Заголовок Strict-Transport-Security говорит браузеру обращаться к домену только по HTTPS в течение заданного срока. Это снижает риск перехвата первоначального HTTP-перехода после того, как политика уже получена. Параметр includeSubDomains распространяет правило на поддомены, а preload требует отдельной готовности и регистрации.

Начинайте с небольшого max-age, проверяйте поддомены и постепенно увеличивайте срок. Не добавляйте includeSubDomains или preload, пока каждый используемый поддомен не поддерживает HTTPS: отмена политики не возвращает доступ мгновенно клиентам, которые уже сохранили прежнее значение.

Калькулятор даты продления

Три контрольные даты

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

Пример метода: сертификат заканчивается 30 ноября; автоматический цикл стартует 1 ноября; тревога срабатывает 15 ноября, если новый сертификат не обслуживается; аварийная эскалация назначена на 23 ноября. Интервалы являются примером, а не универсальной нормой: их выбирают по сроку действия, частоте запуска ACME, времени согласований и критичности сайта.

Мониторинг должен проверять внешний адрес, а не только файл на сервере. После успешного выпуска старый сертификат может продолжить отдавать другой узел кластера, забытый балансировщик или CDN-кэш конфигурации.

Паспорт сертификатов

Поле	Пример записи
Сервис и владелец	Основной сайт, команда эксплуатации
Домены	Корень, www, API и нужные поддомены
Точка TLS	CDN, балансировщик или веб-сервер
Издатель и метод	Удостоверяющий центр, ACME DNS-01
Хранилище ключа	Путь, secret manager или HSM без самого секрета
Продление	Задание, частота, учетная запись
Контроль	Внешний монитор, порог и получатели
Аварийная замена	Инструкция, роли и канал связи

Паспорт показывает владельца и путь замены. Не помещайте в него ключи, пароли DNS или токены ACME: секреты храните отдельно.

Как проверить установленный сертификат

Для диагностики полезны командные инструменты. Команда устанавливает соединение с SNI и показывает цепочку сервера:

openssl s_client -connect example.com:443 -servername example.com -showcerts

Локальный файл можно посмотреть отдельно:

openssl x509 -in certificate.pem -noout -subject -issuer -dates -ext subjectAltName

Проверьте итоговый код верификации, SAN, срок и издателя. Затем повторите тест извне, с IPv4 и IPv6 при их наличии, для каждого узла и доменного варианта. Успешный вывод локального файла еще не доказывает, что именно он установлен в рабочем контуре.

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

сертификат выдан не для того имени или не содержит www;
сервер не отправляет промежуточный сертификат;
закрытый ключ не соответствует открытому ключу сертификата;
часть узлов кластера продолжает отдавать старую версию;
часы сервера или клиента настроены неверно;
страница загружает скрипты, шрифты или API по HTTP;
редирект создает цикл либо теряет путь и параметры;
автоматизация выпуска есть, а установка и reload выполняются вручную;
wildcard используется на слишком многих независимых серверах;
HSTS включен до готовности поддоменов;
монитор проверяет файл, а не публичный endpoint;
сертификат считают заменой защите приложения.

Чек-лист эксплуатации

все публичные домены внесены в реестр;
точки завершения TLS нанесены на схему;
закрытые ключи имеют минимально необходимые права;
цепочка проверяется на чистом клиенте;
поддерживаются актуальные версии TLS и безопасная конфигурация;
HTTP перенаправляется на соответствующий HTTPS URL;
mixed content отсутствует;
продление выполняется автоматически и регулярно тестируется;
внешний монитор предупреждает нескольких ответственных;
есть сценарий утечки ключа, отзыва и срочного перевыпуска;
изменения DNS, CDN и балансировщиков входят в процесс контроля;
HSTS соответствует реальной готовности домена.

Частые вопросы

Нужен ли HTTPS сайту без формы оплаты?

Да. Посетитель передает запросы, cookie и другие данные, а получаемая страница должна быть защищена от подмены в сети. Кроме того, многие возможности браузера рассчитаны на безопасный контекст.

Можно ли использовать самоподписанный сертификат?

Для закрытого контура — если собственный корень контролируемо установлен на всех клиентах. Для публичного сайта такой сертификат не будет автоматически доверенным и вызовет ошибку проверки.

Сертификат привязан к IP-адресу?

Обычно он выдается на доменные имена из SAN. Один IP может обслуживать много HTTPS-сайтов благодаря SNI, а домен может указывать на несколько адресов. Во всех точках должен отдаваться подходящий сертификат.

Почему после продления браузер видит старый сертификат?

Возможны незагруженная конфигурация, другой узел кластера, CDN, балансировщик, IPv6-адрес или неверный файл. Проверьте публичный endpoint по каждому маршруту.

Нужно ли покупать сертификат для каждого поддомена?

Не обязательно: существуют SAN и wildcard. Но совместное покрытие связывает жизненный цикл и риск ключа, поэтому независимым системам часто удобнее отдельная автоматизированная выдача.

Что делать при утечке закрытого ключа?

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

Вывод

SSL-сертификат — это часть инфраструктуры доверия для HTTPS, а не декоративный значок и не универсальная защита сайта. Безопасная эксплуатация начинается с реестра доменов и точек TLS, продолжается правильной цепочкой, защищенным ключом и полным переходом ресурсов на HTTPS, а завершается автоматическим продлением и внешним мониторингом. Выберите тип проверки по реальной задаче, проверьте каждый маршрут и заранее отрепетируйте замену: тогда сертификат будет рабочим механизмом безопасности, а не датой, о которой вспоминают после сбоя.

Редакция ДоверьсяСервису

Эксперты по онлайн-сервисам. Команда проекта проверяет материалы о сервисах, тарифах и задачах, обновляет данные и помогает сравнивать сервисы по фактам.