Відповіді:
SAN (Subject Alternative Name) є частиною специфікації сертифіката X509 , де в сертифікаті є поле зі списком альтернативних імен, які також дійсні для предмета (крім єдиного загального імені / CN). Імена поля та підстановки по суті є двома способами використання одного сертифіката для кількох імен.
SNI (Вказівка імені сервера) - це розширення протоколу TLS, яке є еквівалентом протоколу TLS-протоколу HTTP-заголовка хоста. Коли клієнт надсилає це, він дозволяє серверу вибрати відповідний сертифікат для подання клієнтові без обмеження використання окремих IP-адрес на стороні сервера (подібно до того, як заголовок HTTP Host широко використовується для звичайного HTTP).
Зауважте, що SNI - це не те, що відображено в сертифікаті, і воно фактично досягає певної протилежності тому, що запитує запитання; це спрощує наявність багатьох сертифікатів, не використовуючи один сертифікат для багатьох речей.
З іншого боку, сильно залежить від ситуації, який шлях насправді кращий. Як приклад, те, що запитання задається, майже точно не є тим, що ви насправді хочете, якщо вам потрібні сертифікати для різних організацій.
SAN розшифровується як альтернативне ім’я предмета , і це властивість сертифіката x509, а SNI є функцією, яку клієнт SSL / TLS може підтримувати, таким чином, зовсім інша сутність.
Використовуючи сертифікат з SAN, ви можете розмістити декілька сайтів із підтримкою HTTPS на одній IP-адресі, навіть якщо клієнт не підтримує SNI . У цьому випадку ви тримаєте один сертифікат для всіх своїх сайтів, і такий сертифікат повинен містити всі назви сайтів ( ServerNameів або ServerAliasкодів) в координатах апаша або 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буде містити загальне ім'я з *.foobar.comі SAN з foobar.com.
Це змішує дві частини процесу сертифікації.
SAN - це альтернативна назва предмета. Це спосіб створити один сертифікат для кількох доменів. Ви просто додаєте в довідку інші домени, для яких потрібно сертифікат. Потім браузер прийме дійсність і для цих доменів.
SNI - індикація імені сервера і входить до складу SSL. Це дозволяє розміщувати кілька сайтів SSL в одному IP, оскільки потрібне ім’я сервера надсилається за допомогою рукостискання SSL і сервер може вибрати правильний сертифікат для відповіді.
Ось (можливо) більш зрозуміла для людини відповідь:
SNI проводиться на стороні клієнта і повідомляє стеку TLS "Я хочу поговорити з сервером, ім'я якого - [Сервер X]". Сервер бачить цей рядок [Server X] і відповідає відповідним сертифікатом. Один практичний приклад - коли одному серверу необхідно обслуговувати трафік для кількох доменів. Також корисно, якщо клієнт використовував IP (щоб уникнути затримок пошуку DNS), але сертифікат CN не згадує IP.
SAN - це список "Також відомий як" у сертифікатах. Таким чином сервер може використовувати єдиний сертифікат для багатьох імен. До одного сертифікату можна додати багато доменів і навіть список IP-адрес.
Як бачите, речі перетинаються. Вибір між одним або обома залежить від того, де хто має контроль. Деякі клієнти можуть не розпізнавати імена в SAN і єдиний спосіб їх вирішення - це надання відповідного сертифіката на основі SNI. Існують сценарії, які сервер надає API для одного сертифіката або клієнт не надсилає SNI. У цих випадках SAN - єдиний вихід.
Моя компанія використовує обидва. Вони забезпечують гнучкість і полегшують сумісність назад і вперед.