Ini adalah Pertanyaan Canonical tentang Hosting beberapa situs web SSL pada IP yang sama.

Saya mendapat kesan bahwa setiap Sertifikat SSL memerlukannya sendiri Alamat IP / kombinasi Port yang unik. Tetapi jawaban untuk pertanyaan sebelumnya yang saya posting bertentangan dengan klaim ini.

Menggunakan informasi dari Pertanyaan itu, saya bisa mendapatkan beberapa sertifikat SSL untuk bekerja pada alamat IP yang sama dan pada port 443. Saya sangat bingung mengapa ini bekerja dengan asumsi di atas dan diperkuat oleh yang lain bahwa setiap situs web domain SSL pada server yang sama membutuhkan IP / Port sendiri.

Saya curiga bahwa saya melakukan sesuatu yang salah. Bisakah beberapa Sertifikat SSL digunakan dengan cara ini?

Untuk informasi terkini tentang Apache dan SNI, termasuk RFC khusus HTTP tambahan, silakan merujuk ke Wiki Apache

FYsI: "Beberapa sertifikat SSL (berbeda) pada satu IP" dipersembahkan oleh keajaiban Peningkatan TLS. Ini bekerja dengan server Apache yang lebih baru (2.2.x) dan browser yang cukup baru (tidak tahu versi dari atas kepala saya).

RFC 2817 (meningkatkan ke TLS dalam HTTP / 1.1) memiliki detail berdarah, tetapi pada dasarnya ini bekerja untuk banyak orang (jika bukan mayoritas).
Anda dapat mereproduksi perilaku funky lama dengan s_clientperintah openssl (atau browser "yang cukup").

Edit untuk ditambahkan: tampaknya curldapat menunjukkan kepada Anda apa yang terjadi di sini lebih baik daripada openssl:

SSLv3

mikeg@flexo% curl -v -v -v -3 https://www.yummyskin.com
* About to connect() to www.yummyskin.com port 443 (#0)
*   Trying 69.164.214.79... connected
* Connected to www.yummyskin.com (69.164.214.79) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /usr/local/share/certs/ca-root-nss.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*    subject: serialNumber=wq8O9mhOSp9fY9JcmaJUrFNWWrANURzJ; C=CA; 
              O=staging.bossystem.org; OU=GT07932874;
              OU=See www.rapidssl.com/resources/cps (c)10;
              OU=Domain Control Validated - RapidSSL(R);
              CN=staging.bossystem.org
*    start date: 2010-02-03 18:53:53 GMT
*    expire date: 2011-02-06 13:21:08 GMT
* SSL: certificate subject name 'staging.bossystem.org'
       does not match target host name 'www.yummyskin.com'
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
curl: (51) SSL: certificate subject name 'staging.bossystem.org'
does not match target host name 'www.yummyskin.com'

TLSv1

mikeg@flexo% curl -v -v -v -1 https://www.yummyskin.com
* About to connect() to www.yummyskin.com port 443 (#0)
*   Trying 69.164.214.79... connected
* Connected to www.yummyskin.com (69.164.214.79) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /usr/local/share/certs/ca-root-nss.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*    subject: C=CA; O=www.yummyskin.com; OU=GT13670640;
              OU=See www.rapidssl.com/resources/cps (c)09;
              OU=Domain Control Validated - RapidSSL(R);
              CN=www.yummyskin.com
*    start date: 2009-04-24 15:48:15 GMT
*    expire date: 2010-04-25 15:48:15 GMT
*    common name: www.yummyskin.com (matched)
*    issuer: C=US; O=Equifax Secure Inc.; CN=Equifax Secure Global eBusiness CA-1
*    SSL certificate verify ok.

Ya, tetapi ada beberapa peringatan.

Ini dicapai melalui Indikasi Nama Server, ekstensi untuk Transport Layer Security.

Apa itu Indikasi Nama Server?

Indikasi Nama Server ( RFC 6066 ; usang RFC 4366 , RFC 3546 ) adalah ekstensi untuk Transport Layer Security yang memungkinkan klien untuk memberi tahu server nama host yang hendak dijangkau.

SNI kompatibel dengan TLS 1.0 dan lebih tinggi sesuai dengan spesifikasi, tetapi implementasinya dapat bervariasi (lihat di bawah). Ini tidak dapat digunakan dengan SSL, jadi koneksi harus menegosiasikan TLS (lihat RFC 4346 lampiran E ) agar SNI dapat digunakan. Ini umumnya terjadi secara otomatis dengan perangkat lunak yang didukung.

Mengapa SNI dibutuhkan?

Dalam koneksi HTTP normal , browser menginformasikan server nama host server yang ingin dijangkau menggunakan Host:header. Ini memungkinkan server web pada satu alamat IP untuk menyajikan konten untuk beberapa nama host, yang umumnya dikenal sebagai hosting virtual berbasis nama .

Alternatifnya adalah dengan menetapkan alamat IP unik untuk setiap nama host web yang akan dilayani. Ini biasanya dilakukan pada hari-hari awal web, sebelum diketahui secara luas bahwa alamat IP akan habis dan tindakan konservasi dimulai, dan masih dilakukan dengan cara ini untuk host virtual SSL (tidak menggunakan SNI).

Karena metode transmisi nama host ini memerlukan koneksi yang sudah ada, metode ini tidak berfungsi dengan koneksi SSL / TLS. Pada saat koneksi aman diatur, server web harus sudah tahu nama host mana yang akan digunakan untuk klien, karena server web itu sendiri sedang menyiapkan koneksi aman.

SNI memecahkan masalah ini dengan meminta klien mengirimkan nama host sebagai bagian dari negosiasi TLS, sehingga server sudah mengetahui virtual host mana yang harus digunakan untuk melayani koneksi. Server kemudian dapat menggunakan sertifikat dan konfigurasi untuk host virtual yang benar.

Mengapa tidak menggunakan alamat IP yang berbeda?

Host:Header HTTP didefinisikan untuk memungkinkan lebih dari satu host Web dilayani dari satu alamat IP karena kekurangan alamat IPv4, yang diakui sebagai masalah sejak pertengahan 1990-an. Dalam lingkungan hosting web bersama, ratusan situs Web unik dan tidak terkait dapat dilayani menggunakan alamat IP tunggal dengan cara ini, menghemat ruang alamat.

Lingkungan shared hosting kemudian menemukan bahwa konsumen terbesar dari ruang alamat IP adalah kebutuhan untuk situs web yang aman untuk memiliki alamat IP yang unik, menciptakan kebutuhan akan SNI sebagai tindakan penghenti kesenjangan dalam perjalanan ke IPv6. Saat ini kadang-kadang sulit untuk mendapatkan sedikitnya 5 alamat IP (/ 29) tanpa pembenaran yang signifikan, sering mengakibatkan keterlambatan penyebaran.

Dengan munculnya IPv6, teknik konservasi alamat seperti itu tidak lagi diperlukan, karena satu host dapat memiliki lebih banyak alamat IPv6 yang ditugaskan untuknya daripada seluruh Internet yang ada saat ini, tetapi teknik tersebut mungkin masih akan digunakan jauh ke masa depan untuk melayani warisan IPv4 koneksi.

Peringatan

Beberapa kombinasi sistem operasi / browser tidak mendukung SNI (lihat di bawah), jadi menggunakan SNI tidak sesuai untuk semua situasi. Situs yang menargetkan kombinasi sistem / browser seperti itu harus melupakan SNI dan terus menggunakan alamat IP unik untuk setiap host virtual.

Catatan khusus, tidak ada versi Internet Explorer pada Windows XP yang mendukung SNI. Karena kombinasi ini masih mewakili bagian yang signifikan (tetapi terus menurun; sekitar 16% dari lalu lintas Internet pada bulan Desember 2012 menurut NetMarketShare) dari lalu lintas Internet, SNI tidak akan sesuai untuk situs yang menargetkan populasi pengguna ini.

Dukung

Banyak, tetapi tidak semua, paket perangkat lunak yang umum digunakan mendukung SNI.

(Kelalaian dari daftar ini tidak selalu berarti kurangnya dukungan; itu berarti ada batasan seberapa banyak saya bisa mengetik, atau saya tidak dapat dengan cepat menemukan informasi dalam pencarian. Jika paket perangkat lunak Anda tidak terdaftar, cari untuk namanya plus sniharus mengungkapkan jika ada dukungan dan cara mengaturnya.)

Dukungan Perpustakaan

Sebagian besar paket bergantung pada perpustakaan eksternal untuk memberikan dukungan SSL / TLS.

• GNU TLS
• JSSE (Oracle Java) 7 atau lebih tinggi, hanya sebagai klien
• libcurl 7.18.1 atau lebih tinggi
• NSS 3.1.1 atau lebih tinggi
• OpenSSL 0.9.8j atau lebih tinggi
  • OpenSSL 0.9.8f atau lebih tinggi, dengan mengonfigurasi flag
• Qt 4.8 atau lebih tinggi

Dukungan Server

Sebagian besar versi terbaru dari perangkat lunak server populer mendukung SNI. Instruksi pengaturan tersedia untuk sebagian besar dari ini:

• Apache 2.2.12 atau lebih tinggi
• Apache Traffic Server 3.2.0 atau lebih tinggi
• Cherokee
• HAProxy 1.5 atau lebih tinggi
• IIS 8.0 atau lebih tinggi
• lighttpd 1.4.24 atau lebih tinggi
• LiteSpeed ​​4.1 atau lebih tinggi
• nginx 0,5.32 atau lebih tinggi

Dukungan Klien

Sebagian besar browser web dan agen pengguna baris perintah saat ini mendukung SNI.

Desktop

• Chrome 5 atau lebih tinggi
  • Chrome 6 atau lebih tinggi pada Windows XP
• Firefox 2 atau lebih tinggi
• Internet Explorer 7 atau lebih tinggi, berjalan pada Windows Vista / Server 2008 atau lebih tinggi
  • Internet Explorer pada Windows XP tidak mendukung SNI terlepas dari versi IE
• Konqueror 4.7 atau lebih tinggi
• Opera 8 atau lebih tinggi (mungkin memerlukan TLS 1.1 diaktifkan untuk berfungsi)
• Safari 3.0 pada Windows Vista / Server 2008 atau lebih tinggi, atau Mac OS X 10.5.6 atau lebih tinggi

Mobile

• Browser Android pada 3.0 Honeycomb atau lebih tinggi
• iOS Safari di iOS 4 atau lebih tinggi
• Windows Phone 7 atau lebih tinggi

Garis komando

• CURL 7.18.1 atau lebih tinggi
• wget 1,14 atau lebih tinggi (Distribusi mungkin telah mendukung patch untuk dukungan SNI)

Tidak ada dukungan

• Browser BlackBerry
• Internet Explorer (versi apa pun) pada Windows XP

(Catatan: Beberapa informasi untuk jawaban ini diperoleh dari Wikipedia .)

Masalah:

Ketika klien web dan server web berbicara satu sama lain melalui HTTPS, hal pertama yang perlu terjadi adalah jabat tangan yang aman.

Berikut adalah contoh sederhana dari jabat tangan tersebut:

Jika ini HTTP dan bukan HTTPS, hal pertama yang akan dikirim klien adalah sekitar seperti ini:

GET /index.html HTTP/1.1
Host: example.com

Ini memungkinkan beberapa host virtual pada satu alamat IP, karena server tahu persis domain apa yang ingin diakses klien, yaitu example.com.

HTTPS berbeda. Seperti yang saya katakan sebelumnya, jabat tangan datang sebelum segalanya. Jika Anda melihat langkah ketiga dari jabat tangan yang diilustrasikan di atas (Sertifikat), server harus menunjukkan sertifikat kepada klien sebagai bagian dari jabat tangan, tetapi tidak memiliki petunjuk nama domain apa yang coba diakses oleh klien. Satu-satunya pilihan server adalah mengirim sertifikat yang sama setiap kali, sertifikat standarnya.

Anda masih dapat mengatur host virtual di server web Anda, tetapi server akan selalu mengirim sertifikat yang sama ke setiap klien. Jika Anda mencoba meng-host situs web example.com dan example.org di server Anda, server akan selalu mengirim sertifikat untuk example.com ketika klien meminta koneksi HTTPS. Jadi ketika klien meminta example.org melalui koneksi HTTPS yang telah dibuat, ini akan terjadi:

Masalah ini secara efektif membatasi jumlah domain yang Anda dapat server lebih dari HTTPS ke satu per alamat IP.

Solusinya:

Cara termudah untuk menyelesaikan masalah ini adalah klien memberi tahu server domain mana yang ingin diakses selama jabat tangan . Dengan cara ini server dapat menyajikan sertifikat yang benar.

Inilah yang dilakukan oleh SNI , atau Indikasi Nama Server.

Dengan SNI, klien mengirimkan nama server yang ingin diakses sebagai bagian dari pesan pertama, langkah "Klien Halo" dalam diagram jabat tangan di atas.

Beberapa browser web lama tidak mendukung SNI. Misalnya, pada Windows XP tidak ada versi tunggal dari Internet Explorer yang memiliki dukungan untuk SNI. Saat mengakses sumber daya melalui HTTPS di server yang menggunakan host virtual SNI, Anda akan diberi sertifikat generik, yang dapat menyebabkan browser menampilkan peringatan atau kesalahan.

Saya menyederhanakan hal-hal di sini hanya untuk menjelaskan prinsip di balik masalah dan solusinya. Jika Anda menginginkan penjelasan yang lebih teknis, halaman wikipedia atau RFC 6066 mungkin berfungsi sebagai titik awal yang baik. Anda juga dapat menemukan daftar server dan browser terbaru yang mendukung SNI di wikipedia

http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI

Browser klien juga harus mendukung SNI. Berikut beberapa peramban yang melakukannya:

* Mozilla Firefox 2.0 or later
* Opera 8.0 or later (with TLS 1.1 enabled)
* Internet Explorer 7.0 or later (on Vista, not XP)
* Google Chrome
* Safari 3.2.1 on Mac OS X 10.5.6 

Indikasi nama server (RFC6066) ekstensi TLS diperlukan agar vhosts berbasis nama dapat digunakan di HTTPS.

Ekstensi ini diterapkan secara luas dan saya belum menemukan masalah dengan perangkat lunak saat ini, tetapi ada kemungkinan bahwa beberapa klien (yang tidak mendukungnya) akan dialihkan ke situs default Anda jika Anda bergantung pada SNI.