Что такое SSL-сертификат и зачем он нужен сайту

SSL-сертификат в контексте современного HTTPS — это X.509-сертификат, который помогает клиенту проверить, с каким сервером он устанавливает TLS-соединение, и получить открытый ключ, связанный с удостоверенной идентичностью. На практике корректнее говорить «TLS-сертификат», но термин «SSL-сертификат» по-прежнему широко используется.

Сам сертификат не «шифрует сайт» в одиночку. Шифрование трафика создаёт TLS-протокол, а сертификат участвует в аутентификации стороны и установлении доверия.

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

При подключении к:

https://example.com

клиент должен проверить, что сертификат:

• выдан для нужного hostname;
• находится в периоде действия;
• имеет корректную цепочку доверия;
• не нарушает правила проверки конкретного клиента.

После успешной TLS-проверки устанавливается защищённое соединение.

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

X.509-сертификат содержит, среди прочего:

• сведения об издателе;
• сведения о субъекте;
• публичный ключ;
• серийный номер;
• период действия notBefore / notAfter;
• расширения, включая Subject Alternative Name;
• цифровую подпись издателя.

Для веб-сайта особенно важны SAN, срок действия и цепочка доверия.

Сертификат и приватный ключ — разные вещи

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

Приватный ключ должен оставаться секретным на стороне сервера или TLS termination.

Упрощённо:

certificate → public information
private key → secret

Утечка приватного ключа — инцидент безопасности. Публикация сертификата сама по себе нормальна: браузер получает его при TLS handshake.

Что такое цепочка сертификатов

Обычно клиент получает не только leaf certificate сайта, но и intermediate certificate.

Root CA
   ↓
Intermediate CA
   ↓
example.com

Root CA обычно уже находится в trust store клиента, поэтому сервер чаще передаёт leaf + необходимые intermediate certificates.

Если intermediate chain настроена неправильно, часть клиентов может не суметь построить доверенную цепочку.

Что такое hostname verification

Клиент должен убедиться, что сертификат подходит домену, к которому он подключается.

Например, сертификат для:

api.example.com

не обязан подходить:

shop.example.com

если нужное имя не включено в SAN.

Что такое notBefore и notAfter

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

notBefore → сертификат ещё не должен считаться действительным раньше этой даты
notAfter  → после этой даты сертификат истёк

Подробнее: Как узнать срок действия SSL-сертификата и Что произойдёт после истечения SSL-сертификата.

Что происходит во время TLS handshake

Упрощённо:

client hello
  ↓
server hello + certificate
  ↓
client validates certificate
  ↓
создаются ключи сессии
  ↓
зашифрованный HTTP

Сертификат является только одной частью handshake.

Почему HTTPS может не работать даже с «новым сертификатом»

Причины:

• неверный hostname;
• истёкший certificate;
• certificate ещё не действует;
• неполная chain;
• сервер отдаёт старый certificate;
• SNI выбирает другой virtual host;
• CDN и origin используют разные сертификаты;
• часть load balancer nodes не обновлена.

Как посмотреть фактический сертификат сайта

Через OpenSSL:

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  </dev/null

Для краткого просмотра сертификата:

echo | openssl s_client \
  -connect example.com:443 \
  -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

Смотрите:

• subject;
• issuer;
• notBefore;
• notAfter;
• subjectAltName.

Для общей инструкции см. Как проверить SSL-сертификат сайта.

Почему нужен параметр SNI

Один IP может обслуживать несколько HTTPS-доменов. Клиент сообщает hostname через Server Name Indication, чтобы сервер выбрал нужный сертификат.

Если выполнить диагностическое соединение только по IP без hostname, можно получить сертификат другого virtual host и сделать неверный вывод.

CDN и два разных сертификата

Архитектура может быть такой:

клиент
  ↓ TLS №1
CDN
  ↓ TLS №2
origin

У edge и origin разные сертификаты, разные цепочки и разные notAfter.

Публичный сертификат может быть исправен, а origin certificate — уже нет.

Самоподписанный сертификат

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

Для внутренних систем это иногда допустимо при управляемом trust store. Для публичного сайта нужен сертификат, которому доверяют целевые клиенты.

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

Сам факт оплаты не делает TLS «более зашифрованным». Важны корректная выдача, ключи, алгоритмы, цепочка, срок действия и доверие клиентов.

Разные продукты CA могут давать дополнительные организационные услуги, но базовая задача сертификата в HTTPS — аутентификация в TLS.

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

После deployment:

hostname → совпадает
chain → строится
notBefore → уже наступил
notAfter → в будущем
TLS handshake → успешен
HTTP request → ожидаемый ответ

Если TLS termination распределён, повторите проверку несколько раз или проверьте узлы отдельно.

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

ACME-клиент может получить новый файл, но endpoint продолжит отдавать старый certificate, если не выполнен reload или обновлён не тот узел.

Поэтому контролировать нужно реальный сертификат публичного endpoint, а не только наличие файла на диске.

Связь с мониторингом

UpWatch может контролировать срок SSL-сертификата публичного endpoint и заранее предупреждать о приближении истечения. Это дополняет автоматическое renewal и позволяет обнаружить ситуацию, когда новый сертификат не дошёл до production.

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

• путать сертификат и приватный ключ;
• считать certificate самостоятельным шифрованием;
• проверять только файл на сервере;
• забывать SNI;
• не проверять SAN;
• игнорировать intermediate chain;
• считать успешный renewal доказательством обновления публичного endpoint;
• проверять только CDN, забывая origin.

Практический чек-лист

1. Определить hostname.
2. Получить фактический сертификат endpoint.
3. Проверить SAN.
4. Проверить issuer.
5. Проверить chain.
6. Проверить notBefore.
7. Проверить notAfter.
8. Проверить SNI.
9. Определить TLS termination.
10. Если есть CDN — проверить edge и origin отдельно.
11. Проверить HTTPS-запрос после handshake.
12. Настроить автоматический контроль срока.

Источники и спецификации

• RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile
• RFC 8446: TLS 1.3
• OpenSSL s_client
• OpenSSL x509