Apakah setiap subdomain memerlukan sertifikat SSL sendiri?


41

Saya membuat server websocket yang akan hidup ws.mysite.example. Saya ingin server soket web dienkripsi SSL serta domain.exampledienkripsi SSL. Apakah saya perlu membeli sertifikat baru untuk setiap subdomain yang saya buat? Apakah saya memerlukan alamat IP khusus untuk setiap subdomain yang saya buat? Saya kemungkinan akan memiliki lebih dari satu subdomain.

Saya menggunakan NGINX dan Gunicorn yang berjalan di Ubuntu.

Jawaban:


44

Saya akan menjawab ini dalam dua langkah ...

Apakah Anda Membutuhkan Sertifikat SSL untuk Setiap Subdomain?

Ya dan Tidak, itu tergantung. Sertifikat SSL standar Anda akan untuk domain tunggal, katakanlah www.domain.example. Ada berbagai jenis sertifikat yang dapat Anda singkirkan dari sertifikat domain tunggal standar: sertifikat wildcard dan multi domain.

  • Sebuah cert wild card akan dikeluarkan untuk sesuatu seperti *.domain.exampledan klien akan memperlakukan ini sebagai berlaku untuk setiap domain yang berakhir dengan domain.example, seperti www.domain.exampleatau ws.domain.example.

  • Sertifikat multi domain berlaku untuk daftar nama domain yang telah ditentukan sebelumnya. Ini dilakukan dengan menggunakan bidang Nama Alternatif Subjek pada sertifikat. Misalnya, Anda bisa memberi tahu CA bahwa Anda menginginkan sertifikat multi domain untuk domain.exampledan ws.mysite.example. Ini akan memungkinkannya digunakan untuk kedua nama domain.

Jika tak satu pun dari opsi ini bekerja untuk Anda, maka Anda harus memiliki dua sertifikat SSL yang berbeda.

Apakah Saya Membutuhkan IP Khusus untuk Setiap Subdomain?

Sekali lagi, ini adalah ya dan tidak ... itu semua tergantung pada server web / aplikasi Anda. Saya seorang pria Windows, jadi saya akan menjawab dengan contoh IIS.

  • Jika Anda menjalankan IIS7 atau lebih lama, maka Anda dipaksa untuk mengikat sertifikat SSL ke IP dan Anda tidak dapat memiliki beberapa sertifikat yang ditugaskan untuk satu IP. Ini menyebabkan Anda perlu memiliki IP berbeda untuk setiap subdomain jika Anda menggunakan sertifikat SSL khusus untuk setiap subdomain. Jika Anda menggunakan sertifikat multi domain atau sertifikat wildcard, maka Anda bisa lolos dengan IP tunggal karena Anda hanya memiliki satu sertifikat SSL untuk memulai.

  • Jika Anda menjalankan IIS8 atau lebih baru, maka hal yang sama berlaku. Namun, IIS8 + menyertakan dukungan untuk sesuatu yang disebut Indikasi Nama Server (SNI). SNI memungkinkan Anda untuk mengikat sertifikat SSL ke nama host, bukan ke IP. Jadi nama host (Nama Server) yang digunakan untuk membuat permintaan digunakan untuk menunjukkan sertifikat SSL mana yang harus digunakan IIS untuk permintaan tersebut.

  • Jika Anda menggunakan IP tunggal, maka Anda dapat mengonfigurasi situs web untuk menanggapi permintaan nama host tertentu.

Saya tahu bahwa Apache dan Tomcat juga memiliki dukungan untuk SNI, tetapi saya tidak cukup mengenal mereka untuk mengetahui versi apa yang mendukungnya.

Intinya

Bergantung pada aplikasi / server web Anda dan jenis sertifikat SSL apa yang dapat Anda peroleh akan menentukan opsi Anda.


Saya menggunakan gunicorn dan nginx di Ubuntu.
user974407

Dalam hal itu, SNI harus tersedia selama OpenSSL (untuk nginx) dipenuhi dengan dukungan SNI. Sesuai tautan dalam jawaban GomoX.
pkeenan

Beberapa sertifikat sub-domain mendaftar domain utama sebagai alternatif, sehingga Anda mungkin menemukan Anda dapat melakukan www.domain.com dan domain.com pada satu sertifikat pada satu alamat IP. Berhati-hatilah untuk mempertimbangkan audiens target Anda ketika mempertimbangkan SNI: IE pada XP tidak mendukungnya yang akan memengaruhi Anda dengan beberapa pengguna korporat, begitu pula beberapa browser seluler lama seperti stock Android setidaknya hingga 2.3.5 yang perlu Anda pertimbangkan jika Anda menargetkan perangkat seluler (di sini ada banyak perangkat Android yang menjalankan versi lama).
David Spillett

@pkeenan - Akan lebih baik jika jawabannya diperbarui untuk mencerminkan fitur teknis yang mendukung nama host dan domain tanpa nama host - helpdesk.ssls.com/hc/en-us/articles/…
Termotivasi

> klien akan memperlakukan ini sebagai valid untuk domain apa pun yang berakhir dengan 'domain.com', seperti 'www.domain.com' atau 'ws.domain.com'. Ini membuat saya percaya bahwa itu juga berlaku untuk abc.def.domain.com, apakah itu juga masalahnya?
Jeff

7

Anda bisa mendapatkan sertifikat untuk setiap subdomain, beberapa sertifikat subdomain, atau sertifikat wildcard (untuk *.yoursite.example).

Biayanya biasanya sedikit lebih mahal daripada sertifikat biasa, dan karena Anda berbagi satu sertifikat, mereka biasanya bukan pilihan terbaik dari sudut pandang keamanan kecuali jika Anda meng-host anything.mydomain.examplejenis aplikasi yang merupakan satu-satunya pilihan yang bisa diterapkan.

Anda juga tidak memerlukan banyak alamat IP jika Anda memiliki server web yang mendukung SNI . Ini mengatakan, SNI hanya didukung di browser modern (IE6 dan di bawahnya tidak akan berfungsi dengan itu). Versi terbaru dari Nginx dan Apache mendukung SNI secara transparan (cukup tambahkan host virtual yang diaktifkan SSL).


Apa yang Anda maksud dengan "bukan pilihan terbaik dari sudut pandang keamanan"?
Termotivasi

4
Satu sertifikat yang dibagikan untuk semua host Anda mengubah setiap pelanggaran sertifikat menjadi ancaman keamanan tingkat domain, bukan hanya memengaruhi subdomain apa pun yang dilampirkan dengan sertifikat itu. Misalnya, sertifikat yang digunakan untuk www.yoursite.com yang merupakan pemasangan WordPress akan sama dengan yang untuk pembayaran.yoursite.com yang merupakan aplikasi pemrosesan kartu kredit aman. Jika yang pertama bocor, yang kedua terganggu.
GomoX

0

Anda akan memerlukan sertifikat terpisah untuk setiap subdomain, atau Anda dapat membeli sertifikat wildcard ( *.domain.example) - lebih mahal, tetapi masuk akal jika Anda meng-hosting banyak subdomain.

Mengenai IP, itu tergantung pada bagaimana Anda mengatur server Anda. Anda dapat menggunakan aturan nama host untuk melayani beberapa situs dari IP yang sama, atau menggunakan IP unik untuk masing-masing situs. Ada pro dan kontra untuk kedua metode ini.

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.