SNI и ALPN: как браузер выбирает сертификат и протокол

Что же такое SNI и ALPN?

При установке HTTPS‑соединения браузер и сервер должны решить две задачи: какой TLS‑сертификат использовать и какой прикладной протокол будет работать поверх TLS. Для этого используются расширения протокола — SNI и ALPN.

SNI (Server Name Indication) позволяет клиенту передать серверу доменное имя ещё во время TLS‑handshake. Это важно, когда на одном IP‑адресе размещено несколько сайтов с разными сертификатами.

ALPN (Application‑Layer Protocol Negotiation) используется для выбора прикладного протокола: например HTTP/1.1, HTTP/2 или HTTP/3.

Если вам нужен подробный разбор самого TLS‑рукопожатия и его пакетов, в блоге есть отдельная статья на эту тему.

Здесь мы сосредоточимся именно на том, как в процессе handshake выбираются сертификат и протокол.

Где в handshake используются SNI и ALPN

Во время TLS‑рукопожатия клиент отправляет первое сообщение — ClientHello. В нём содержатся различные расширения TLS.

Среди них:

SNI — доменное имя, к которому обращается клиент
ALPN — список поддерживаемых прикладных протоколов

Сервер использует эти данные для выбора конфигурации соединения.

Упрощённая схема выглядит так:

Браузер открывает TCP‑соединение.
Отправляет ClientHello.
В ClientHello передаются SNI и ALPN.
Сервер выбирает сертификат и протокол.
Продолжается стандартный TLS‑handshake.

Как работает SNI

До появления SNI сервер во время TLS‑handshake не знал, к какому именно домену обращается клиент. HTTP‑заголовок Host приходит уже после установления TLS‑соединения, когда сертификат давно отправлен.

Поэтому раньше для каждого HTTPS‑сайта требовался отдельный IP‑адрес.

SNI решает эту проблему. Браузер передаёт домен прямо в ClientHello.

Например:

server_name: example.com

Получив это значение, сервер может выбрать правильный виртуальный хост и соответствующий сертификат.

Это позволяет размещать десятки и сотни HTTPS‑сайтов на одном IP.

Как сервер выбирает сертификат

На стороне веб‑сервера алгоритм обычно выглядит так:

Получить ClientHello.
Извлечь значение SNI.
Найти виртуальный хост с этим доменом.
Отправить соответствующий TLS‑сертификат.

Если подходящего хоста нет, сервер использует сертификат по умолчанию.

Именно поэтому при ошибках конфигурации можно увидеть ситуацию, когда браузер получает сертификат от другого домена.

Как работает ALPN

После выбора сертификата сервер должен определить, какой прикладной протокол будет использоваться.

Раньше практически весь веб работал через HTTP/1.1. Но современные браузеры поддерживают HTTP/2 и HTTP/3, поэтому нужен механизм согласования.

ALPN решает эту задачу.

Клиент отправляет список поддерживаемых протоколов, например:

h2
http/1.1

Сервер выбирает один из них и сообщает об этом в ServerHello.

Если поддерживается HTTP/2 — соединение будет работать через "h2". Если нет — используется HTTP/1.1.

Если интересно, как меняется транспортный уровень при переходе на QUIC, см. статью «Что такое HTTP3 (QUIC) и чем он отличается от HTTP2 на практике».

Как сервер выбирает протокол

Выбор через ALPN происходит довольно просто:

Клиент отправляет список протоколов.
Сервер проверяет, какие из них поддерживает.
Выбирается первый подходящий вариант.

Например:

клиент: h2, http/1.1
сервер поддерживает: h2

Результат — соединение работает по HTTP/2.

Если совпадений нет, сервер обычно откатывается к HTTP/1.1.

Как посмотреть SNI и ALPN на практике

Эти параметры можно легко проверить через стандартные инструменты.

openssl

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

Флаг -servername задаёт SNI.

В выводе можно увидеть:

выбранный сертификат
версию TLS
согласованный протокол ALPN

curl

curl -I -v https://example.com

В диагностическом выводе будет строка вида:

ALPN, server accepted to use h2

Это означает, что соединение работает через HTTP/2.

браузер

В инструментах разработчика (DevTools) во вкладке Network есть колонка Protocol, где можно увидеть http/1.1, h2 или h3.

Типичные проблемы

Несколько распространённых ошибок инфраструктуры связаны именно с SNI и ALPN.

Неверный сертификат

Если сервер возвращает сертификат другого домена, чаще всего проблема в конфигурации виртуальных хостов или в отсутствии SNI.

HTTP/2 не используется

Иногда сервер поддерживает HTTP/2, но браузер продолжает использовать HTTP/1.1. Обычно это означает, что HTTP/2 не включён в ALPN или отключён в конфигурации сервера.

Старые клиенты

Очень старые браузеры и системы не поддерживают SNI. В таких случаях сайты на shared‑хостинге могут работать некорректно, потому что сервер не может определить нужный сертификат.

Итог

SNI и ALPN — ключевые расширения TLS, которые делают возможным современный HTTPS‑хостинг.

SNI сообщает серверу, для какого домена устанавливается соединение, и позволяет выбрать правильный сертификат. ALPN отвечает за выбор прикладного протокола — HTTP/1.1, HTTP/2 или HTTP/3.

Понимание этих механизмов помогает быстрее диагностировать проблемы с сертификатами, конфигурацией веб‑серверов и работой HTTPS‑соединений.