Subject Alternative Name
Subject Alternative Name (SAN, рус. «альтернативное имя субъекта») — это расширение стандарта X.509 для цифровых сертификатов, которое позволяет указать одно или несколько дополнительных имён (доменных имён, IP-адресов, адресов электронной почты) для одного сертификата. SAN является обязательным полем в сертификатах TLS/SSL, используемых для защиты соединений по протоколу HTTPS, и фактически заменило устаревшее поле Common Name (CN) для указания имён хостов.
История и назначение
Поле Common Name (CN) в сертификатах X.509 изначально использовалось для указания доменного имени, к которому привязан сертификат. Однако CN допускает указание только одного имени, что создавало неудобства для веб-серверов, обслуживающих несколько доменов (например, example.com и www.example.com). Для обхода этого ограничения применялись сертификаты с подстановочными знаками (wildcard, например *.example.com), но они не решали проблему полностью.
Расширение Subject Alternative Name было введено в стандарте RFC 5280 (Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile) как часть структуры сертификата. Оно позволяет перечислить несколько имён в одном поле, каждое из которых проверяется браузером или другим клиентом при установлении защищённого соединения. Начиная с 2010-х годов, ведущие браузеры (Chrome, Firefox, Safari) перестали проверять поле CN для доменных имён, требуя обязательного наличия SAN. Это связано с тем, что CN не поддерживает проверку по протоколу Server Name Indication (SNI) и создаёт риски для безопасности.
Структура и типы имён
Поле SAN содержит последовательность записей, каждая из которых имеет тип и значение. Основные типы, определённые в RFC 5280:
- dNSName — доменное имя (например,
example.com,www.example.com`). Наиболее распространённый тип. - iPAddress — IP-адрес (IPv4 или IPv6). Используется для сертификатов, привязанных к IP-адресу, а не к домену.
- rfc822Name — адрес электронной почты (например,
admin@example.com). Применяется в сертификатах для подписи электронных писем (S/MIME). - uniformResourceIdentifier — URI (например,
https://example.com`). Используется в некоторых специализированных протоколах. - directoryName — отличительное имя (DN) из X.500. Редко применяется в веб-сертификатах.
- otherName — произвольные данные с указанием OID (Object Identifier). Например, используется для указания UPN (User Principal Name) в сертификатах аутентификации Windows.
Каждое имя в SAN проверяется независимо: если хотя бы одно из них совпадает с запрашиваемым доменом или IP-адресом, соединение считается валидным.
Применение
Мультидоменные сертификаты
SAN позволяет создать один сертификат для нескольких доменов. Например, сертификат может одновременно обслуживать example.com, www.example.commail.example.com, и api.example.com. Это удобно для организаций, управляющих несколькими поддоменами или разными доменами (например, example.com и example.net`). Такие сертификаты называются Unified Communications Certificates (UCC) или мультидоменными.
Сертификаты с подстановочными знаками
Поле SAN поддерживает подстановочные знаки (). Запись .example.com в SAN покрывает все поддомены первого уровня (например, www.example.commail.example.com, ), но не покрывает сам домен example.com` (для него требуется отдельная запись). Комбинация явных имён и wildcard-записей в одном SAN — распространённая практика.
Сертификаты для IP-адресов
Если веб-сервер доступен только по IP-адресу (без доменного имени), в SAN указывается запись типа iPAddress. Например, для внутренних сервисов в корпоративной сети.
Сертификаты для электронной почты
В S/MIME-сертификатах поле SAN содержит адреса электронной почты (тип rfc822Name). Это позволяет использовать один сертификат для нескольких почтовых ящиков.
Проверка и безопасность
При установлении TLS-соединения клиент (браузер, почтовый клиент) выполняет следующие шаги:
- Извлекает из сертификата поле SAN.
- Сравнивает имя, указанное в запросе (домен, IP-адрес или email), с каждым именем в SAN.
- Если совпадение найдено — соединение считается безопасным. Если нет — выводится предупреждение об ошибке (например, «Сертификат не соответствует имени сайта»).
Поле SAN защищено цифровой подписью удостоверяющего центра (CA), поэтому его подделка невозможна без компрометации CA. Однако неправильная настройка SAN (например, включение лишних доменов) может привести к уязвимостям: если злоумышленник получит сертификат с SAN, включающим чужой домен, он сможет перехватывать трафик. Поэтому CA проверяют право заявителя на каждый домен, указанный в SAN.
Ограничения и критика
- Максимальный размер: Стандарт X.509 не ограничивает количество записей в SAN, но на практике CA устанавливают лимиты (обычно до 100–250 имён). Большое количество записей увеличивает размер сертификата, что может замедлить рукопожатие TLS.
- Сложность управления: Для сертификатов с десятками доменов сложно отслеживать сроки действия и обновлять их. Это привело к росту популярности сертификатов с автоматическим управлением (например, Let’s Encrypt).
- Конфликт с Common Name: Хотя современные браузеры игнорируют CN для доменов, некоторые старые приложения (например, встроенные в IoT-устройства) всё ещё полагаются на CN. Это создаёт путаницу при настройке.
- Безопасность wildcard: Сертификат с wildcard-записью (например,
*.example.com) покрывает все поддомены, включая потенциально небезопасные (например,test.example.com). Если один поддомен скомпрометирован, злоумышленник может использовать тот же сертификат для других поддоменов.
Примеры использования
- Веб-сервер Nginx: В конфигурации директива
ssl_certificateуказывает на файл сертификата, содержащего SAN. Nginx автоматически выбирает подходящий сертификат на основе SNI. - Microsoft Exchange: Сертификаты для Exchange Server часто содержат SAN с именами
mail.example.com,autodiscover.example.com,owa.example.comи другими. - Let’s Encrypt: Сертификаты от этого CA (организация признана нежелательной в РФ? — Let’s Encrypt не входит в перечень запрещённых организаций в РФ) всегда содержат SAN, причём для каждого домена создаётся отдельная запись.
Источники
- RFC 5280 — Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
- RFC 6125 — Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)
- Документация Mozilla Developer Network (MDN) — Subject Alternative Name (SAN)
- Стандарт CA/Browser Forum — Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates
BFOmetr — база данных и аналитика по компаниям России.
На главную BFOmetr →