Интернет «по умолчанию» недоверчив: между вашим браузером и сервером есть провайдеры, маршрутизаторы, публичные Wi‑Fi, промежуточные узлы. Если данные идут «в открытую», их можно перехватить или подменить. Именно здесь и появляется TLS — современный протокол, который исторически до сих пор часто называют «SSL».
Важно: термин SSL в быту живёт до сих пор, но современные браузеры и серверы используют TLS (Transport Layer Security). Когда говорят «SSL‑сертификат», почти всегда имеют в виду сертификат для TLS/HTTPS.
Что такое SSL/TLS и зачем это нужно
TLS решает сразу три задачи:
Конфиденциальность — никто по пути не читает ваш трафик (логины, пароли, cookies, данные форм).
Целостность — данные нельзя незаметно изменить в дороге.
Аутентификация — вы подключились именно к тому серверу/сайту, а не к поддельной копии.
На практике это означает:
сайт работает по HTTPS;
браузер показывает «замочек»;
формы авторизации, платежи, админ‑панели и API защищены.
TLS применим не только к сайтам: он используется и для почты (SMTP/IMAP/POP3 через STARTTLS или TLS‑порты), IP‑телефонии, различных клиент‑серверных приложений и внутренних сервисов.
SSL vs TLS: что поменялось
Исторически был протокол SSL, но он устарел. На смену пришёл TLS (это эволюция идей SSL).
Что важно новичку:
не пытайтесь «включать SSL» как отдельный «старый режим» — это небезопасно;
в настройках серверов ищите «TLS versions» и включайте только современные версии (обычно TLS 1.2/1.3);
сертификаты называются «SSL‑сертификатами» по привычке, но работают для TLS.
Как работает TLS: рукопожатие (handshake) без лишней магии
Чтобы шифровать трафик, клиент и сервер должны договориться о параметрах безопасности и ключах. Этот процесс называют TLS‑рукопожатием.
Ниже — понятная схема (упрощённо, но логика верная):
Шаг 1. Клиент начинает разговор
Браузер (клиент) отправляет серверу запрос: «Хочу безопасное соединение. Вот список поддерживаемых версий TLS и наборов шифров».
Шаг 2. Сервер отвечает и присылает сертификат
Сервер выбирает подходящие параметры и отправляет сертификат (а иногда и цепочку сертификатов).
Шаг 3. Клиент проверяет сертификат
Браузер проверяет:
совпадает ли домен в сертификате с адресом сайта;
не истёк ли срок;
не отозван ли сертификат;
доверяет ли он тому, кто подписал сертификат (центру сертификации);
корректна ли цепочка доверия.
Если проверка не проходит — вы видите предупреждение в браузере.
Шаг 4. Обмен ключами (key exchange)
Дальше клиент и сервер договариваются о сеансовом симметричном ключе (именно им потом будет быстро шифроваться весь трафик).
Сертификат нужен как «документ личности» сервера и как часть механизма безопасного согласования ключей.
Симметричный ключ выбирают так, чтобы его нельзя было перехватить даже при наличии трафика.
Шаг 5. Шифрованный канал готов
С этого момента:
всё, что отправляет клиент, шифруется;
сервер расшифровывает и отвечает тоже шифрованно;
по пути трафик остаётся «нечитабельным».
Что такое TLS/SSL‑сертификат
Сертификат — это файл (точнее, набор данных), который доказывает:
«Этот публичный ключ принадлежит этому доменному имени (и/или организации)».
Сертификат обычно содержит:
доменное имя (или список имён: SAN);
публичный ключ;
срок действия;
данные центра сертификации (CA), который его подписал;
информацию о владельце (для OV/EV — организацию).
Закрытый (приватный) ключ сертификата хранится только на вашем сервере. Его нельзя публиковать и нельзя терять. Если приватный ключ утёк — сертификат нужно перевыпускать.
Кто такие центры сертификации (CA) и как устроено доверие
Центр сертификации (CA) — это организация, которой доверяют браузеры и операционные системы. В них встроен список доверенных корневых сертификатов.
Идея проста:
CA проверяет заявителя (по правилам выбранного типа сертификата);
CA подписывает ваш сертификат;
браузер, увидев подпись знакомого CA, говорит: «Ок, этому можно верить».
Чаще всего на сервере используется цепочка:
ваш сертификат (leaf)
промежуточный сертификат (intermediate)
корневой сертификат (root) — обычно уже есть у клиента, на сервере его ставить не нужно.
Типы сертификатов: какой выбрать
Тип сертификата определяет уровень проверки (а не «силу шифрования»).
DV (Domain Validation) — проверка домена
Подтверждается только владение доменом.
Самый быстрый и дешёвый вариант.
Отлично подходит для: личных сайтов, блогов, лендингов, внутренних сервисов, тестовых стендов.
OV (Organization Validation) — проверка организации
Подтверждается домен + юридическая организация.
Уместно для корпоративных сайтов, сервисов с поддержкой клиентов.
EV (Extended Validation) — расширенная проверка
Самая строгая проверка заявителя.
Исторически использовался как «максимум доверия» для e‑commerce.
При этом шифрование такое же, как у DV/OV — разница именно в проверке владельца.
Wildcard — сертификат на поддомены
Формат:
*.example.comЗащищает поддомены первого уровня (например,
api.example.com,panel.example.com).Не покрывает «глубже» (например,
a.b.example.com), если это не предусмотрено отдельно.
Multi‑Domain / SAN (один сертификат на много доменов)
Один сертификат может содержать список доменов и поддоменов.
Удобно, когда проектов много, а управлять хочется проще.
Практический совет:
один сайт/сервис → чаще всего DV;
корпоративный сайт или бренд‑сервис с публичной поддержкой → OV;
много поддоменов одного проекта → Wildcard;
много разных доменов → SAN/Multi‑Domain.
Бесплатные и платные сертификаты: в чём реальная разница
Бесплатные (например, Let’s Encrypt)
Плюсы:
бесплатно;
автоматизация выпуска/продления;
достаточная безопасность для большинства задач.
Минусы (обычно организационные):
чаще короткий срок действия (что компенсируется автопродлением);
нет OV/EV‑проверки (обычно выпускаются как DV).
Платные (коммерческие CA)
Плюсы:
доступны OV/EV;
иногда удобные доп.сервисы (страхование, поддержка, корпоративные процессы).
Минусы:
стоимость;
без правильной настройки на сервере «платность» не спасёт от технических ошибок.
Главное правило: безопасность соединения чаще ломается не «плохим сертификатом», а неправильной установкой, отсутствием цепочки, устаревшими TLS‑версиями или ошибками DNS/времени на сервере.
Как проверить, есть ли сертификат и всё ли с ним хорошо
Быстро (для пользователя)
адрес начинается с
https://;«замочек» в браузере → можно посмотреть сведения о сертификате.
Технически (для сисадмина)
Если есть доступ к консоли — полезно уметь проверить руками.
Проверка цепочки и данных сертификата:
openssl s_client -connect example.com:443 -servername example.com -showcerts
Проверка ответа сервера по HTTPS:
curl -Iv https://example.com/
Смотрите на:
срок действия (
notBefore/notAfter),совпадение домена,
наличие intermediate‑сертификатов,
выбранную версию TLS.
Как получить сертификат: понятный алгоритм владельца сайта
Независимо от того, бесплатный сертификат или платный, логика обычно одинакова.
Шаг 1. Выберите тип сертификата
Определитесь: DV/OV/EV, Wildcard, SAN.
Шаг 2. Подготовьте домен
Нужно, чтобы домен указывал на ваш сервер (A/AAAA записи), а также чтобы у вас был доступ к DNS (или к веб‑серверу) для подтверждения владения.
Шаг 3. Сгенерируйте ключ и CSR (для платных CA)
CSR (Certificate Signing Request) — это «заявка на сертификат», содержащая публичный ключ и данные домена/организации.
Пример (универсально):
openssl req -new -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr
example.com.key— приватный ключ (храните аккуратно!)example.com.csr— то, что отправляется в CA
Шаг 4. Подтвердите владение доменом
Самые частые методы:
DNS‑проверка (TXT запись) — лучший вариант, особенно для Wildcard.
HTTP‑проверка — CA просит разместить файл в определённом пути на сайте.
Email‑проверка — реже используется и зависит от провайдера.
Шаг 5. Получите сертификат и установите на сервер
Вам понадобится:
ваш сертификат;
цепочка промежуточных (если требуется);
приватный ключ.
Дальше конфигурация зависит от веб‑сервера (Nginx/Apache/Caddy) или панели управления.
Установка: что важно не перепутать
Новички чаще всего ошибаются в трёх местах:
Не тот сертификат / не тот домен
Сертификат должен соответствовать FQDN, к которому подключаются пользователи.
Потеряли или перепутали приватный ключ
Сертификат «работает» только с тем приватным ключом, с которым создавался CSR.
Не установили цепочку (intermediate)
В браузерах это проявляется ошибками доверия, хотя «сертификат вроде есть».
Если используете обратный прокси (reverse proxy), важно понимать, где заканчивается TLS:
TLS на прокси → трафик между клиентом и прокси шифрован; дальше прокси может ходить к бэкенду по HTTP или по внутреннему TLS.
TLS до бэкенда → повышает безопасность внутри инфраструктуры.
Мини‑чеклист «правильного» HTTPS для продакшна
Чтобы HTTPS был не «для галочки», а реально надёжным:
включены только современные TLS‑версии (обычно TLS 1.2/1.3);
отключены старые шифры и компромиссные настройки;
настроено автопродление (особенно для Let’s Encrypt);
включён редирект
http → https;включён HSTS (если понимаете последствия) для защиты от downgrade‑атак;
корректно выставлено время на сервере (NTP), иначе сертификаты «вдруг становятся недействительными».
Частые проблемы и как их диагностировать
«Сайт небезопасен», хотя сертификат установлен
Обычно причина:
не хватает intermediate‑сертификата;
сертификат не на тот домен;
открыт другой сайт/виртуальный хост на 443.
«Сертификат истёк»
Причина:
не настроено автопродление;
крон/таймер Certbot не запускается;
валидация не проходит из‑за DNS/файрвола.
«Не открывается у части пользователей»
Возможные причины:
очень старые устройства не поддерживают новые цепочки/алгоритмы;
сервер настроен только на TLS 1.3, а клиент умеет только 1.2;
проблемы с SNI при нестандартных клиентах.
Итоги
TLS (то, что многие называют SSL) — это основа безопасного интернета. Понимание трёх вещей уже делает вас сильнее большинства новичков:
сертификат = удостоверение личности + публичный ключ;
приватный ключ должен быть в безопасности;
TLS‑рукопожатие создаёт сеансовый ключ и дальше шифрует весь трафик.
Если вы хотите, чтобы статья была практической «под ваш стек» (Nginx/Apache/Caddy, панель управления, Cloudflare, Docker), — можно добавить отдельный раздел с пошаговой установкой и примерами конфигов именно для вашей платформы.