Czy ktoś mógłby wyjaśnić mi różnicę między tymi certyfikatami w uproszczony sposób? Czytam niektóre artykuły, ale wygląda na to, że wykonują tę samą pracę, a mianowicie szyfrują wiele domen za pomocą jednego certyfikatu.
Odpowiedzi:
SAN (alternatywna nazwa podmiotu) jest częścią specyfikacji certyfikatu X509 , w której certyfikat zawiera pole z listą alternatywnych nazw, które są również ważne dla podmiotu (oprócz pojedynczej nazwy wspólnej / CN). Nazwy pól i symboli wieloznacznych są zasadniczo dwoma sposobami używania jednego certyfikatu dla wielu nazw.
SNI (Server Name Indication) to rozszerzenie protokołu TLS, które jest swego rodzaju protokołem TLS równoważnym nagłówkowi hosta HTTP. Gdy klient wysyła to, pozwala serwerowi wybrać odpowiedni certyfikat, który ma zostać przedstawiony klientowi, bez ograniczenia korzystania z oddzielnych adresów IP po stronie serwera (podobnie jak w przypadku zwykłego używania HTTP nagłówka hosta HTTP).
Zauważ, że SNI nie jest czymś odzwierciedlonym w certyfikacie i faktycznie osiąga coś wręcz przeciwnego do tego, o co pyta pytanie; upraszcza to posiadanie wielu certyfikatów, nieużywanie jednego certyfikatu do wielu rzeczy.
Z drugiej strony zależy to w dużej mierze od sytuacji, która ścieżka jest rzeczywiście preferowana. Na przykład pytanie, o które pyta, prawie na pewno nie jest tym, czego naprawdę chcesz, jeśli potrzebujesz certyfikatów dla różnych podmiotów.
SAN oznacza alternatywną nazwę podmiotu i jest to właściwość certyfikatu x509, a SNI to funkcja obsługiwana przez klienta SSL / TLS, a więc zupełnie inna jednostka.
Korzystając z certyfikatu z siecią SAN , możesz hostować wiele witryn obsługujących HTTPS pod jednym adresem IP, nawet jeśli klient nie obsługuje SNI . W takim przypadku należy przytrzymać jeden certyfikat dla wszystkich stron, a takie świadectwo musi zawierać wszystkie nazwy serwis ( ServerNames lub ServerAliases we współrzędnych apache, lub server_namew nginx) jak to SAN . Jest to podzbiór dotychczasowego podejścia, który rozszerzył „jedną witrynę z obsługą HTTPS na każdym oddzielnym adresie IP”. Obecnie tylko duże sieci CDN trzymają się SAN .
Za pomocą SNI możesz również hostować wiele witryn z obsługą HTTPS pod jednym adresem IP, posiadasz osobny certyfikat x509 dla każdej witryny i żadna z nich nie wymienia innych nazw witryn we właściwościach SAN , ale klientów TLS (tj. Przeglądarek i klientów konsolowych, takich jak wgetlub curl) musi obsługiwać SNI . Jest to nowoczesne podejście, ponieważ ostatnim systemem operacyjnym, który nie obsługuje SNI po wyjęciu z pudełka, był Windows XP z IE 6.x, jeśli dobrze pamiętam. Obecnie można zobaczyć SAN własność jeśli zakup wieloznaczny certyfikatu - na przykład za pomocą takiego świadectwa *.foobar.combędą zawierać Common Name of *.foobar.comoraz SAN z foobar.com.
To łączy dwie części procesu certyfikacji.
SAN to alternatywna nazwa podmiotu. Jest to sposób na utworzenie jednego certyfikatu dla wielu domen. Po prostu dodajesz inne domeny, dla których chcesz uzyskać certyfikat, do pola SAN w certyfikacie. Przeglądarka zaakceptuje również ważność w tych domenach.
SNI to wskazanie nazwy serwera i jest częścią protokołu SSL. Pozwala hostować wiele witryn SSL pod jednym adresem IP, ponieważ żądana nazwa serwera jest wysyłana z uzgadnianiem SSL, a serwer może wybrać odpowiedni certyfikat dla odpowiedzi.
Oto (prawdopodobnie) bardziej czytelna dla człowieka odpowiedź:
SNI jest przeprowadzany po stronie klienta i mówi stosowi TLS „Chcę porozmawiać z serwerem o nazwie [Serwer X]”. Serwer widzi ten ciąg [Server X] i odpowiada odpowiednim certyfikatem. Jednym praktycznym przykładem jest sytuacja, gdy jeden serwer musi obsługiwać ruch dla wielu domen. Jest to również przydatne, jeśli klient użył adresu IP (aby uniknąć opóźnień wyszukiwania DNS), ale certyfikat CN nie wspomina o adresie IP.
SAN to lista „Znanych również jako” w certyfikatach. W ten sposób serwer może używać jednego certyfikatu dla wielu nazw. Do tego samego certyfikatu można dodać wiele domen, a nawet listę adresów IP.
Jak widać, rzeczy nakładają się. Wybór jednego lub obu zależy od tego, nad którym się ma kontrolę. Niektórzy klienci mogą nie rozpoznawać nazw w sieci SAN i jedynym sposobem na adres jest dostarczenie odpowiedniego certyfikatu opartego na SNI. Istnieją scenariusze, w których serwer udostępnia interfejs API dla jednego certyfikatu lub klient nie wysyła SNI. W takich przypadkach SAN jest jedynym wyjściem.
Moja firma korzysta z obu. Zapewniają elastyczność i ułatwiają kompatybilność wstecz i do przodu.