--- title: 'Что такое SSL‑сертификат и как он работает | Zomro' description: '' image: 'https://cdn.zomro.com/uploads/blog/a48%40server-panel.net/2025/12/29/chatgpt-image-29-2025-21_38_51_q50.jpg' --- ![opened image]() * [Zomro](https://zomro.com/rus/) * [FAQ](https://zomro.com/rus/blog/faq/) * Что такое SSL‑сертификат и как он работает # Что такое SSL‑сертификат и как он работает 14-12-2025 ![](https://cdn.zomro.com/uploads/blog/a48%40server-panel.net/2025/12/29/chatgpt-image-29-2025-21_38_51_q50.jpg) Интернет «по умолчанию» недоверчив: между вашим браузером и сервером есть провайдеры, маршрутизаторы, публичные Wi‑Fi, промежуточные узлы. Если данные идут «в открытую», их можно перехватить или подменить. Именно здесь и появляется **TLS** — современный протокол, который исторически до сих пор часто называют «SSL». > **Важно:** термин _SSL_ в быту живёт до сих пор, но современные браузеры и серверы используют **TLS** (Transport Layer Security). Когда говорят «SSL‑сертификат», почти всегда имеют в виду **сертификат для TLS/HTTPS**. ## Что такое SSL/TLS и зачем это нужно **TLS** решает сразу три задачи: 1. **Конфиденциальность** — никто по пути не читает ваш трафик (логины, пароли, cookies, данные форм). 2. **Целостность** — данные нельзя незаметно изменить в дороге. 3. **Аутентификация** — вы подключились именно к тому серверу/сайту, а не к поддельной копии. На практике это означает: * сайт работает по **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 — организацию). > **Закрытый (приватный) ключ** сертификата хранится только на вашем сервере. Его нельзя публиковать и нельзя терять. Если приватный ключ утёк — сертификат нужно перевыпускать. ![](https://cdn.zomro.com/uploads/blog/a48%40server-panel.net/2025/12/29/chatgpt-image-29-2025-21_38_59_q50.jpg) ## Кто такие центры сертификации (CA) и как устроено доверие **Центр сертификации (CA)** — это организация, которой доверяют браузеры и операционные системы. В них встроен список доверенных корневых сертификатов. Идея проста: * CA проверяет заявителя (по правилам выбранного типа сертификата); * CA подписывает ваш сертификат; * браузер, увидев подпись знакомого CA, говорит: «Ок, этому можно верить». Чаще всего на сервере используется **цепочка** : * ваш сертификат (leaf) * промежуточный сертификат (intermediate) * корневой сертификат (root) — обычно уже есть у клиента, на сервере его ставить не нужно. ![](https://cdn.zomro.com/uploads/blog/a48%40server-panel.net/2025/12/29/chatgpt-image-29-2025-21_40_19_q50.jpg) ## Типы сертификатов: какой выбрать Тип сертификата определяет **уровень проверки** (а не «силу шифрования»). ### 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://cdn.zomro.com/uploads/blog/a48%40server-panel.net/2025/12/29/chatgpt-image-29-2025-21_42_20_q50.jpg) ## Как проверить, есть ли сертификат и всё ли с ним хорошо ### Быстро (для пользователя) * адрес начинается с `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) или панели управления. ## Установка: что важно не перепутать Новички чаще всего ошибаются в трёх местах: 1. **Не тот сертификат / не тот домен** * Сертификат должен соответствовать FQDN, к которому подключаются пользователи. 2. **Потеряли или перепутали приватный ключ** * Сертификат «работает» только с тем приватным ключом, с которым создавался CSR. 3. **Не установили цепочку (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) — это основа безопасного интернета. Понимание трёх вещей уже делает вас сильнее большинства новичков: 1. **сертификат = удостоверение личности + публичный ключ** ; 2. **приватный ключ должен быть в безопасности** ; 3. **TLS‑рукопожатие создаёт сеансовый ключ и дальше шифрует весь трафик**. Если вы хотите, чтобы статья была практической «под ваш стек» (Nginx/Apache/Caddy, панель управления, Cloudflare, Docker), — можно добавить отдельный раздел с пошаговой установкой и примерами конфигов именно для вашей платформы. Похожие статьи [Как установить и настроить PHP на Windows Server](https://zomro.com/rus/blog/faq/363-how-to-install-and-configure-php-on-windows-server) [Как подключить свой образ ISO к выделенному серверу](https://zomro.com/rus/blog/faq/234-kak-podkljuchit-svoj-obraz-iso-k-vydelennomu-serveru) [Отключение автоматической установки обновлений Windows](https://zomro.com/rus/blog/faq/426-otklyuchenie-avtomaticheskoj-ustanovki-obnovlenij-windows) [В чём разница между серверами? Их преимущества и недостатки](https://zomro.com/rus/blog/faq/498-what-are-the-differences-between-servers-their-advantages-and-disadvantages) [Выполнение бекапов сайта и базы данных простым скриптом через планировщик](https://zomro.com/rus/blog/faq/369-performing-site-and-database-backups-with-a-simple-script-through-the-scheduler) [ Виртуальный хостинг от €3.98/мес ](/rus/virtual)