Apa perbedaan antara sertifikat SAN dan SNI SSL?


21

Bisakah seseorang menjelaskan perbedaan antara sertifikat-sertifikat ini dengan cara yang disederhanakan? Saya membaca beberapa artikel tetapi sepertinya mereka melakukan pekerjaan yang sama, yaitu mengenkripsi banyak domain dengan satu sertifikat.


11
Ya, pertama, tidak ada yang namanya sertifikat SSL "SNI".
Michael Hampton

Jawaban:


36

SAN (Nama Alternatif Subjek) adalah bagian dari spesifikasi sertifikat X509 , di mana sertifikat tersebut memiliki bidang dengan daftar nama alternatif yang juga berlaku untuk subjek (di samping satu Nama Umum / CN). Bidang ini dan nama wildcard pada dasarnya adalah dua cara menggunakan satu sertifikat untuk beberapa nama.

SNI (Server Name Indication) adalah ekstensi protokol TLS yang merupakan semacam protokol TLS yang setara dengan HTTP Host-header. Ketika klien mengirim ini, itu memungkinkan server untuk memilih sertifikat yang tepat untuk disajikan kepada klien tanpa batasan untuk menggunakan alamat IP yang terpisah di sisi server (seperti bagaimana header HTTP Host banyak digunakan untuk HTTP biasa).

Perlu dicatat bahwa SNI bukanlah sesuatu yang tercermin dalam sertifikat dan itu benar-benar mencapai kebalikan dari apa yang ditanyakan oleh pertanyaan; itu menyederhanakan memiliki banyak sertifikat, tidak menggunakan satu sertifikat untuk banyak hal.

Di sisi lain, itu sangat tergantung pada situasi jalan mana yang sebenarnya lebih disukai. Sebagai contoh, pertanyaan yang diajukan hampir pasti bukan yang sebenarnya Anda inginkan jika Anda memerlukan sertifikat untuk entitas yang berbeda.


2
Perlu dicatat bahwa CN telah lama tidak digunakan, jika sebuah nama ada di CN tetapi bukan SAN (atau jika sertifikat tidak memiliki bidang SAN), banyak klien akan marah pada Anda.
coderanger

1
@coderanger Jika ada bidang SAN, bidang CN diabaikan oleh sebagian besar klien. Jika tidak ada bidang SAN, bidang CN berfungsi dengan sebagian besar klien (dan jika mereka marah kepada saya, itu tidak muncul).
kubanczyk

1
Mereka menilai Anda diam-diam.
womble

Apakah SNI mirip dengan host virtual di mana server dengan mengatakan satu alamat IP menampung beberapa host yang didefinisikan dalam konfigurasi HTTP? (semacam multiplexing: menggunakan satu IP untuk beberapa sertifikat alih-alih setiap sertifikat dengan IP berbeda, di mana IPv4 adalah sumber daya yang langka saat ini)?
Fernando Gabrieli

1
@FernandoGabrieli Ya, ini memungkinkan jenis pengaturan berbasis nama yang sama pada level TLS.
Håkan Lindqvist

14

SAN adalah singkatan dari Subject Alternative Name , dan ini merupakan properti sertifikat x509, dan SNI adalah fitur yang dapat didukung oleh klien SSL / TLS, sehingga entitas yang sama sekali berbeda.

Menggunakan sertifikat dengan SAN, Anda dapat meng-host beberapa situs yang mendukung HTTPS pada satu alamat IP bahkan jika klien tidak mendukung SNI . Dalam hal ini Anda memegang satu sertifikat untuk semua situs Anda, dan sertifikat tersebut harus berisi semua nama situs ( ServerNameatau ServerAliasdalam koordinat apache, atau server_namedalam nginx) karena SAN . Ini adalah subset dari pendekatan legacy, yang memperluas "satu situs yang mengaktifkan HTTPS di setiap alamat IP yang terpisah". Saat ini hanya CDN besar yang tetap dengan SAN .

Dengan menggunakan SNI, Anda juga dapat meng-host beberapa situs yang mendukung HTTPS pada satu IP, Anda memegang sertifikat x509 terpisah untuk setiap situs dan tidak satupun dari ini menyebutkan nama situs lain di properti SAN mereka , tetapi klien TLS (yaitu browser dan klien konsol seperti wgetatau curl) harus mendukung SNI . Ini adalah pendekatan modern, karena OS terakhir yang tidak mendukung SNI out-of-the-box adalah Windows XP dengan IE 6.x, jika saya ingat dengan benar. Saat ini Anda dapat melihat SAN properti jika Anda membeli wildcard sertifikat - misalnya sertifikat tersebut untuk *.foobar.comakan berisi Nama umum dari *.foobar.comdan SAN dari foobar.com.


1
Secara teknis, saya tidak percaya bahwa klien SSL dapat mendukung SNI (setahu saya ini adalah ekstensi TLS yang belum pernah muncul di SSL).
Håkan Lindqvist

3
Baik SAN dan SNI memerlukan dukungan klien. Namun karena SAN telah ada jauh lebih lama, ini lebih banyak didukung.
kasperd

4

Ini menggabungkan dua bagian dari proses sertifikat.

SAN adalah Nama Alternatif Subjek. Ini adalah cara untuk membuat satu sertifikat untuk banyak domain. Anda cukup menambahkan domain lain yang Anda inginkan untuk sertifikat ke bidang SAN di sertifikat. Browser kemudian akan menerima validitas pada domain-domain ini juga.

SNI adalah Indikasi Nama Server dan merupakan bagian dari SSL. Ini memungkinkan Anda untuk meng-host beberapa situs SSL pada satu IP karena nama server yang diinginkan dikirim dengan jabat tangan SSL dan server dapat memilih sertifikat yang benar untuk jawabannya.


0

Berikut ini (mungkin) jawaban yang lebih bisa dibaca manusia:

SNI dilakukan di sisi klien dan memberi tahu tumpukan TLS "Saya ingin berbicara dengan server yang bernama [Server X]". Server melihat string [Server X] ini dan membalas dengan sertifikat yang sesuai. Salah satu contoh praktis adalah ketika satu server perlu melayani lalu lintas untuk beberapa domain. Ini juga berguna jika klien menggunakan IP (untuk menghindari keterlambatan pencarian DNS) tetapi sertifikat CN tidak menyebutkan IP.

SAN adalah daftar "Juga Dikenal Sebagai" dalam sertifikat. Dengan cara ini server dapat menggunakan satu sertifikat untuk banyak nama. Satu dapat menambahkan banyak domain ke sertifikat yang sama dan bahkan daftar IP.

Seperti yang Anda lihat, semuanya tumpang tindih. Memilih antara satu atau keduanya tergantung di mana seseorang memiliki kendali atas. Beberapa klien mungkin tidak mengenali nama dalam SAN dan satu-satunya cara untuk mengatasinya adalah dengan memberikan sertifikat yang sesuai berdasarkan SNI. Ada beberapa skenario dimana server menyediakan API untuk satu sertifikat atau klien tidak mengirim SNI. Untuk kasus-kasus ini, SAN adalah satu-satunya jalan keluar.

Perusahaan saya memanfaatkan keduanya. Mereka memberikan fleksibilitas dan membuat kompatibilitas mundur dan maju lebih mudah.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.