Когда человек открывает https://example.com, буква S в конце HTTPS означает, что браузер не просто отправляет запрос серверу. Сначала они договариваются о защищённом соединении — и только после этого внутри него начинают передаваться страницы, пароли, cookies, формы и API-запросы.
На этом этапе появляются слова вроде TLS, сертификат, закрытый ключ, центр сертификации и шифрование. Выглядит серьёзно. Но если разобрать процесс по шагам, HTTPS оказывается вполне понятной системой.
HTTP сам по себе не защищает данные
Обычный HTTP решает простую задачу: браузер отправляет запрос, сервер возвращает ответ. Например:
GET /profile HTTP/1.1
Host: example.comПроблема в том, что HTTP сам по себе не гарантирует защищённость пути между браузером и сервером. Если кто-то получает возможность наблюдать такой трафик, содержимое потенциально можно прочитать или изменить.
HTTPS добавляет защищённый слой. Это не совершенно новый веб-протокол: привычный HTTP работает внутри TLS-соединения.
Что именно даёт HTTPS
У HTTPS есть три главные задачи: шифрование, целостность и проверка сервера. Они нужны одновременно.
Где в нашей цепочке находится HTTPS
После DNS и Nginx путь запроса можно дополнить:
DNS уже нашёл IP. Браузер подключился к серверу. Но прежде чем отправить обычный HTTP-запрос, он устанавливает TLS-соединение. Поэтому ошибка сертификата — уже не ошибка DNS: предыдущий этап, скорее всего, успешно завершён.
Почему используется порт 443
Для обычного HTTP стандартно используется порт 80, для HTTPS — 443. Поэтому адрес https://example.com обычно означает соединение с example.com:443.
server {
listen 443 ssl;
server_name example.com;
}Но теперь серверу недостаточно знать только имя сайта. Для HTTPS понадобятся сертификат и закрытый ключ.
Что такое сертификат
Сертификат можно представить как цифровое удостоверение сайта. Он позволяет браузеру проверить, для какого домена выдан и какой открытый ключ с ним связан.
Сам сертификат не является секретом. Сервер спокойно отправляет его браузеру — в этом и смысл. Секрет находится в другом месте.
Открытый и закрытый ключ
У сервера есть пара связанных ключей. Открытый можно показывать. Закрытый должен оставаться только на сервере.
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;Если сертификат похож на удостоверение личности, закрытый ключ ближе к подписи, которую способен поставить только настоящий владелец.
Зачем нужен закрытый ключ
Представим, что кто-то скопировал сертификат сайта. Этого недостаточно, чтобы успешно изображать оригинальный сервер. Во время установления защищённого соединения сервер должен доказать, что действительно обладает соответствующим закрытым ключом.
Поэтому красивого сертификата недостаточно: нужен секрет, который хранится у настоящего сервера.
Кто подтверждает сертификат
Если сервер сам говорит «я example.com, поверьте мне», это не очень сильное доказательство. Поэтому существует система доверенных центров сертификации — Certificate Authorities, или CA.
Браузеры и операционные системы содержат набор корневых центров, которым доверяют. Браузер проверяет цепочку подписей и решает, можно ли считать сертификат действительным.
Что проверяет браузер
Браузеру мало просто увидеть файл сертификата. Он проверяет, подходит ли тот для домена, не истёк ли срок действия, подписан ли доверенной цепочкой и может ли сервер доказать владение соответствующим закрытым ключом.
Если всё в порядке, соединение продолжается. Если нет — браузер предупреждает пользователя.
Почему сертификат не выдаётся навсегда
У сертификатов есть срок действия. Это не бюрократическая прихоть: если ключ был украден или забытая конфигурация годами живёт без контроля, она не должна автоматически считаться доверенной вечность.
Современная инфраструктура поэтому рассчитана на регулярное автоматическое обновление сертификатов.
Что делает Let's Encrypt
Let's Encrypt — центр сертификации, который сделал получение обычных TLS-сертификатов автоматизированным и широко доступным.
Сервер доказывает контроль над доменом, центр сертификации проверяет доказательство и выдаёт сертификат. Позже процесс повторяется автоматически — например, через Certbot или другой ACME-клиент.
Как сервер доказывает контроль домена
Центру сертификации нужно убедиться, что сертификат не просит случайный человек. Один из способов — временно разместить специальный файл на сайте. Центр обращается к домену и проверяет его содержимое.
Другой вариант — создать специальную DNS-запись. Смысл одинаков: показать, что заявитель действительно управляет доменом.
Почему HTTPS зависит от предыдущих слоёв
Чтобы автоматическая проверка домена сработала, DNS уже должен вести на правильный сервер, а сервер должен быть доступен извне. Получается естественная последовательность:
Если перескочить несколько этапов, выпуск сертификата может не пройти. Поэтому ошибка HTTPS иногда начинается раньше — на DNS или сетевой доступности.
Что происходит во время TLS-соединения
Подробная криптография TLS заслуживает отдельного курса, но для понимания сайта достаточно общей картины.
Браузер и сервер согласуют параметры, сервер отправляет сертификат, браузер его проверяет, а затем стороны получают секретные данные для конкретной сессии. И уже ими шифруется основной трафик.
Асимметричная криптография удобна для установления доверия и обмена, а для большого объёма данных используются быстрые симметричные алгоритмы. TLS сочетает эти механизмы.
Один секрет на весь интернет не используется
HTTPS не означает, что у сайта есть один пароль для всех посетителей. Каждое соединение получает собственные параметры сессии. Два человека, одновременно открывшие сайт, не обязаны шифровать трафик одним и тем же ключом.
Это важно: отдельная сессия не должна превращаться в единый вечный секрет всего сайта.
Что видит посторонний наблюдатель
HTTPS скрывает содержимое соединения: текст формы, cookies, ответы API и HTML не должны читаться просто потому, что кто-то наблюдает трафик.
Но HTTPS не делает пользователя невидимым. IP-адреса существуют, остаются размеры и время передачи пакетов, а DNS имеет собственную модель защиты. HTTPS защищает конкретную вещь — соединение между клиентом и сервером.
HTTPS не означает, что сайт хороший
Это важная граница. HTTPS не говорит, что владельцу сайта можно доверять деньги или личные данные. Он подтверждает защищённость соединения с конкретным доменным именем.
Почему сертификат может быть правильным, а сайт всё равно сломан
Потому что сертификат — только один слой. DNS может работать, TLS успешно установиться, сертификат быть действительным, а приложение за Nginx — отвечать ошибкой.
Если сайт показывает 500 или 502, перевыпуск сертификата обычно не поможет. TLS уже сделал свою работу.
Почему HTTP работает, а HTTPS — нет
Это очень полезный симптом. Если http://example.com открывается, а https://example.com нет, базовый сервер доступен, но проблема находится в HTTPS-части.
Зачем перенаправлять HTTP на HTTPS
После настройки защищённой версии обычно хочется, чтобы посетители всегда использовали именно её. Для этого HTTP-блок может делать только редирект.
server {
listen 80;
server_name example.com;
return 301 https://example.com$request_uri;
}HTTP остаётся входной точкой, но нормальная работа сайта идёт через 443.
Что такое mixed content
Иногда сама страница открывается через HTTPS, но часть ресурсов загружается через HTTP. Например:
<img src="http://example.com/photo.jpg">
<script src="http://example.com/app.js"></script>Это называется mixed content. Браузеры относятся к нему строго и некоторые ресурсы блокируют. Правильный сайт должен последовательно использовать HTTPS и для страницы, и для её зависимостей.
Сертификат должен совпадать с именем
Если сертификат выпущен для example.com, а пользователь открывает shop.example.com, это уже другое имя. Оно должно быть включено в сертификат.
Существуют сертификаты с несколькими именами и wildcard-сертификаты вроде *.example.com. Главное правило простое: домен в браузере должен подходить сертификату, который показывает сервер.
Как Nginx выбирает сертификат для сайта
На одном IP могут жить несколько HTTPS-сайтов. Сертификат нужно выбрать ещё до того, как обычный HTTP-запрос полностью начнётся. Для этого используется SNI — Server Name Indication.
Поэтому один IP спокойно обслуживает основной сайт, API, магазин и другие домены с разными сертификатами.
Почему неправильный сертификат иногда означает неправильный сайт
Если сервер отдаёт сертификат другого домена, это может быть признаком того, что Nginx выбрал не тот HTTPS-блок. Причиной бывают неправильный server_name, отсутствующая конфигурация или сервер по умолчанию.
Сертификат в таком случае помогает диагностировать не только TLS, но и маршрутизацию внутри Nginx.
Проверять HTTPS лучше по слоям
Вместо попытки перевыпустить всё сразу полезнее пройти систему последовательно:
Чем раньше найден сломанный участок, тем меньше настроек придётся трогать. Если домен уже указывает на правильный IP — DNS оставляем в покое. Если TLS устанавливается — смотрим сертификат и Nginx.
Не отключайте проверку только потому, что она мешает
Когда браузер предупреждает о сертификате, самый лёгкий путь — проигнорировать предупреждение. Для локального теста это иногда допустимо, но на публичном сайте правильнее исправить причину.
Неверный домен — исправляем домен. Истёк сертификат — обновляем. Сервер показывает чужой сертификат — проверяем Nginx. DNS ведёт не туда — исправляем DNS.
Хороший HTTPS почти незаметен
Для обычного посетителя правильно настроенный HTTPS скучен. Сайт просто открывается. Никаких предупреждений, ручных подтверждений и заметных пауз. Сертификаты обновляются автоматически, Nginx подхватывает правильные файлы, HTTP переводит на HTTPS.
Это идеальное состояние: безопасность инфраструктуры лучше всего работает тогда, когда пользователь о ней почти не думает.
Вся цепочка сайта теперь почти полная
Теперь можно собрать весь путь одного открытия страницы:
Человек вводит адрес. DNS находит IP. Браузер подключается к 443. Начинается TLS, сервер показывает сертификат, браузер его проверяет, создаётся защищённый канал. Уже внутри него отправляется HTTP-запрос. Nginx выбирает сайт и возвращает страницу.
HTTPS не должен быть магией
За HTTPS скрывается серьёзная криптография, но владельцу сайта необязательно начинать с формул. Сначала важнее понимать роли.