В чем разница между сертификатами SAN и SNI SSL?
SAN (Альтернативное имя субъекта) является частью спецификации X509 сертификата , где сертификат имеет поле со списком альтернативных имен, которые также действительны для субъект (в дополнение к единственному Common Name / CN). Это поле и подстановочные знаки - это, по сути, два способа использования одного сертификата для нескольких имен.
SNI (указание имени сервера) - это расширение протокола TLS , которое является своего рода эквивалентом протокола TLS для HTTP-заголовок Host. Когда клиент отправляет это, это позволяет серверу выбрать правильный сертификат для представления клиенту без ограничения использования отдельных IP-адресов на стороне сервера (так же, как заголовок HTTP Host активно используется для простого HTTP).
Обратите внимание, что SNI - это не то, что отражено в сертификате, и на самом деле он обеспечивает нечто противоположное тому, о чем спрашивает вопрос; это упрощает использование множества сертификатов, а не использование одного сертификата для многих вещей.
С другой стороны, в значительной степени зависит от ситуации, какой путь фактически предпочтительнее. Например, вопрос, о котором идет речь, почти наверняка не то, что вам действительно нужно, если вам нужны сертификаты для разных объектов.
SAN означает Альтернативное имя субъекта , и это свойство сертификата x509, а SNI - это функция, которую клиент SSL / TLS может поддерживать, таким образом, совершенно другой объект.
Используя сертификат с SAN , вы можете разместить несколько сайтов с поддержкой HTTPS на одном IP-адресе, даже если клиент не поддерживает SNI ]. В этом случае у вас есть один сертификат для всех ваших сайтов, и такой сертификат должен содержать все имена сайтов ( ServerName s или ServerAlias es в координатах apache, или server_name в nginx), поскольку это SAN . Это подмножество устаревшего подхода, который расширил «один сайт с поддержкой HTTPS на каждый отдельный IP-адрес». В настоящее время только крупные CDN используют SAN .
Используя SNI , вы также можете разместить несколько сайтов с поддержкой HTTPS на одном IP-адресе, у вас есть отдельный сертификат x509 для каждого сайта, и ни один из они упоминают другие имена сайтов в своем свойстве SAN , но клиенты TLS (т. е. браузеры и консольные клиенты, такие как wget или curl ) должны поддерживать SNI . Это современный подход, поскольку последней ОС, не поддерживающей SNI из коробки, была Windows XP с IE 6.x, если я правильно помню. В настоящее время свойство SAN можно увидеть, если вы приобретете сертификат подстановочного знака - например, такой сертификат для *. Foobar.com будет содержать Common Имя из *. Foobar.com и SAN из foobar.com .
Это смешивает две части процесса сертификата.
SAN - это альтернативное имя субъекта. Это способ создать один сертификат для нескольких доменов. Вы просто добавляете другие домены, для которых хотите получить сертификат, в поле SAN сертификата. Затем браузер примет действительность и в этих доменах.
SNI - это указание имени сервера, являющееся частью SSL. Он позволяет размещать несколько сайтов SSL на одном IP-адресе, поскольку желаемое имя сервера отправляется с подтверждением SSL, и сервер может выбрать правильный сертификат для ответа.
Здесь (возможно) более понятный человеку ответ:
SNI проводится на стороне клиента и говорит TLS стеку "Я хочу поговорить с сервером, чье имя [Server X]". Сервер видит эту строку [Server X] и отвечает соответствующим сертификатом. Один из практических примеров - это когда один сервер должен обслуживать трафик для нескольких доменов. Это также полезно, если клиент использовал IP (чтобы избежать задержек DNS поиска), но сертификат CN не упоминает IP.
SAN - это список "Also Known As" в сертификатах. Таким образом, сервер может использовать один сертификат для многих имен. Можно добавить много доменов к одному и тому же сертификату и даже список IP-адресов.
Как вы видите, вещи перекрываются. Выбор между одним или обоими зависит от того, где у вас есть контроль. Некоторые клиенты могут не распознавать имена в SAN и единственный способ адресации - это предоставление соответствующего сертификата на основе SNI. Существуют сценарии, когда сервер предоставляет API для одного сертификата или клиент не посылает SNI. Для таких случаев единственным выходом является SAN
Моя компания использует оба способа. Они обеспечивают гибкость и упрощают обратную и прямую совместимость
.