Yanıtlar:
SAN (Konu Alternatif Adı), sertifikanın konu için geçerli olan alternatif adların bir listesini içeren bir alana sahip olduğu (tek Ortak Ad / CN'ye ek olarak ), X509 sertifika spesifikasyonunun bir parçasıdır . Bu alan ve joker karakter esas olarak, birden fazla ad için bir sertifika kullanmanın iki yoludur.
SNI (Sunucu Adı Gösterimi), HTTP Ana Bilgisayar başlığına eşdeğer bir TLS protokolü türü olan bir TLS protokol uzantısıdır . Bir müşteri bunu gönderdiğinde, sunucunun sunucu tarafında ayrı IP adresleri kullanma sınırlaması olmadan müşteriye sunmak için uygun sertifikayı seçmesine izin verir (HTTP Ana Bilgisayarı başlığının düz HTTP için nasıl kullanıldığı gibi).
SNI'nin sertifikaya yansıyan bir şey olmadığını ve aslında sorunun ne sorduğunun tam tersi olduğunu not edin; birçok sertifikaya sahip olmayı basitleştirir, birçok şey için bir sertifika kullanmaz.
Diğer taraftan, esas olarak hangi yolun gerçekten tercih edilebileceği durumuna bağlıdır. Örnek olarak, sorunun sorduğu şey, kesin olarak, kesinlikle farklı varlıklar için sertifikalara ihtiyacınız olduğunda istediğinizi değil.
SAN , Konu Alternatif Adı anlamına gelir ve bu bir x509 sertifika özelliğidir ve SNI , SSL / TLS istemcisinin destekleyebileceği bir özelliktir, bu nedenle tamamen farklı bir varlıktır.
SAN ile bir sertifika kullanarak , istemci SNI'yi desteklemese bile, bir IP adresinde birden çok HTTPS etkin siteyi barındırabilirsiniz . Bu durumda size sitelerin tümü için tek bir belgeye sahip ve bu sertifika (site adlarının tüm içermelidir ServerNameler veya ServerAliasapache koordinatlarında es ya server_nameda olduğu gibi nginx içinde) SAN'ları . Bu, "her ayrı IP adresinde" bir HTTPS etkin siteyi "genişleten eski bir yaklaşımın alt kümesidir. Şu anda sadece büyük CDN'ler SAN'a bağlı .
SNI kullanarak , aynı zamanda birden fazla HTTPS etkin siteyi bir IP'de barındırabilir, her site için ayrı bir x509 sertifikası vardır ve bunlardan hiçbiri SAN mülklerinde diğer site adlarından bahsetmez , ancak TLS istemcileri (ör. Tarayıcılar ve konsol istemcileri wgetveya gibi curl) SNI'yi desteklemesi gerekir . Bu, modern bir yaklaşımdır, çünkü SNI'yla birlikte kullanılmayan son işletim sistemi , doğru hatırlıyorsam, IE 6.x yüklü Windows XP idi. Günümüzde Gördüğünüz SAN satın lütfen tesise joker örneği sertifika için - sertifika *.foobar.combir içerecektir Ortak Adını ait *.foobar.comve SAN arasında foobar.com.
Bu, sertifika işleminin iki bölümünü karıştırır.
SAN, Alternatif Bir Konu Adıdır. Birden çok alan için bir sertifika oluşturmanın bir yoludur. Sertifika istediğiniz diğer alanları, sertifikadaki SAN alanına eklemeniz yeterlidir. Tarayıcı daha sonra bu alanlardaki geçerliliği de kabul edecektir.
SNI, Sunucu Adı Göstergesidir ve SSL'nin bir parçasıdır. Tek bir IP üzerinde birden fazla SSL sitesi barındırmanıza izin verir, çünkü istenen sunucu adı SSL el sıkışması ile gönderilir ve sunucu cevap için doğru sertifikayı seçebilir.
İşte (muhtemelen) daha fazla okunabilir bir cevap:
SNI istemci tarafında yürütülür ve TLS yığına "Adı [Sunucu X]" olan bir sunucuyla konuşmak istiyorum "ifadesini kullanır. Sunucu bu [Sunucu X] dizesini görür ve uygun bir sertifika ile yanıtlar. Pratik bir örnek, tek bir sunucunun birden çok etki alanı için trafik sunması gerektiğindedir. İstemcinin bir IP kullanması (DNS arama gecikmelerini önlemek için) kullanması yararlıdır, ancak CN sertifikası IP'den bahsetmez.
SAN, sertifikalardaki "Aynı zamanda Farklı Olarak Bilinir" in bir listesidir. Bu şekilde sunucu birçok isim için tek bir sertifika kullanabilir. Biri aynı sertifikaya birçok etki alanı ve hatta bir IP listesi ekleyebilir.
Gördüğünüz gibi işler çakışıyor. Biri veya her ikisi arasında seçim yapmak, birinin kontrolünü yaptığı yere bağlıdır. Bazı istemciler SAN'daki adları ve SNI'ye dayalı uygun sertifika sağlamanın tek yolunu tanımamış olabilir. Sunucunun tek bir sertifika için API sağladığı veya istemcinin SNI gönderemediği senaryolar vardır. Bu durumlar için SAN tek çıkış yolu.
Şirketim ikisini de kullanıyor. Esneklik sağlar, geriye ve ileriye uyumluluğu kolaylaştırır.