Bu, aynı IP’de birden fazla SSL web sitesini barındırma konusunda Kanonik bir Soru .

Her SSL Sertifikasının kendi benzersiz IP Adres / Port kombinasyonunu gerektirdiği izlenimini edindim. Ancak daha önce sorduğum bir sorunun cevabını bu iddia ile alâkalı.

Bu sorudaki bilgileri kullanarak, aynı IP adresinde ve 443 numaralı bağlantı noktasında çalışmak için birden fazla SSL sertifikası alabildim. Bunun neden yukarıda belirtilen varsayımların verildiğine ve diğerleri tarafından her SSL etki alanı web sitesinde bulunan diğer kişiler tarafından güçlendirildiğine dair kafam çok karıştı. Aynı sunucu kendi IP / Bağlantı Noktasını gerektirir.

Yanlış bir şey yaptığımdan şüpheleniyorum. Birden fazla SSL Sertifikası bu şekilde kullanılabilir mi?

Ek HTTP'ye Özel RFC'ler dahil Apache ve SNI hakkında en güncel bilgiler için lütfen Apache Wiki'ye başvurun.

Bilginize: "Bir IP’de birden fazla (farklı) SSL sertifikası" TLS Yükseltme sihirbazıyla size getirildi. Daha yeni Apache sunucuları (2.2.x) ve oldukça yeni tarayıcılarla çalışıyor (kafamın üstündeki sürümleri bilmiyor).

RFC 2817 (HTTP / 1.1 dahilinde TLS’ye yükseltme) kanlı ayrıntılara sahiptir, ancak temelde birçok kişi için çalışır (çoğunluğu değilse).
Eski korkak davranışı, openssl s_clientkomutuyla (ya da "yeterince eski" herhangi bir tarayıcıyla) yeniden oluşturabilirsiniz.

Eklemek için düzenleyin: görünüşe göre curlsize burada olanları openssl'dan daha iyi gösterebilir:

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.

Evet, ama bazı uyarılar var.

Bu, Aktarım Katmanı Güvenliğinin bir uzantısı olan Sunucu Adı Göstergesi aracılığıyla gerçekleştirilir.

Sunucu Adı Göstergesi Nedir?

Sunucu Adı Gösterimi ( RFC 6066 ; eski RFC 4366 , RFC 3546 ), müşterinin sunucuya ulaşmaya çalıştığı ana bilgisayarın adını söylemesini sağlayan Aktarım Katmanı Güvenliği'nin bir uzantısıdır .

SNI, teknik özelliklere göre TLS 1.0 ve üzeri ile uyumludur, ancak uygulamalar değişebilir (aşağıya bakınız). SSL ile kullanılamaz, bu yüzden bağlantının SNI'yi kullanması için TLS ile görüşmesi gerekir (bkz. RFC 4346 ek E ). Bu genellikle desteklenen yazılımla otomatik olarak gerçekleşir.

SNI neden gerekli?

Normal bir HTTP bağlantısında tarayıcı, Host:başlık kullanarak ulaşmaya çalıştığı sunucunun ana bilgisayar adını sunucuya bildirir . Bu, tek bir IP adresindeki bir web sunucusunun, genellikle ad tabanlı sanal barındırma olarak bilinen birden fazla ana bilgisayar adı için içerik sunmasını sağlar .

Alternatif, sunulacak her web ana bilgisayar adı için benzersiz IP adresleri atamaktır. Bu genellikle webin ilk günlerinde, IP adreslerinin tükeneceği ve koruma önlemlerinin başlayacağı yaygın olarak bilinmeden önce yapıldı ve hala SSL sanal ana bilgisayarları için (SNI kullanmadan) bu şekilde yapıldı.

Bu ana bilgisayar adını iletme yöntemi bağlantının önceden kurulmasını gerektirdiğinden, SSL / TLS bağlantılarıyla çalışmaz. Güvenli bağlantı kurulduğunda, web sunucusunun istemciye hangi ana bilgisayar adını sunacağını zaten bilmesi gerekir, çünkü web sunucusunun kendisi güvenli bağlantı kurmaktadır.

SNI bu sorunu, müşterinin TLS anlaşmasının bir parçası olarak ana bilgisayar adını iletmesini sağlayarak sunucunun bağlantıya hizmet etmek için hangi sanal ana bilgisayarın kullanılması gerektiğinin farkındadır. Sunucu daha sonra doğru sanal ana bilgisayar için sertifikayı ve yapılandırmayı kullanabilir.

Neden farklı IP adresleri kullanmıyorsunuz?

HTTP Host:üstbilgisi, IPv4 adreslerinin yetersizliği nedeniyle, 1990'ların ortaları kadar bir sorun olarak kabul edilen, birden fazla Web sunucusunun tek bir IP adresinden sunulmasına izin verecek şekilde tanımlandı. Paylaşılan web barındırma ortamlarında, yüzlerce benzersiz, ilgisiz Web sitesi, bu şekilde tek bir IP adresi kullanarak sunulabilir ve adres alanını korur.

Paylaşılan barındırma ortamları daha sonra en büyük IP adres alanı tüketicisinin, güvenli web sitelerinin benzersiz IP adreslerine sahip olma gereksinimi olduğunu ve bu da SNI gereksinimini IPv6 yolunda bir durgunluk önlemi olarak yarattığını belirtti. Bugün, önemli ölçüde gerekçesiz olarak sık sık dağıtım gecikmeleri ile sonuçlanan 5 IP adresi (/ 29) 'dan az elde etmek bazen zordur.

IPv6'nın ortaya çıkmasıyla, böyle bir adres koruma tekniği artık gerekli değildir, çünkü tek bir ana bilgisayar, bugünün tüm İnternet'in içerdiğinden daha fazla IPv6 adresine sahip olabilir, ancak teknikler muhtemelen eski IPv4'e hizmet etmek için ileride kullanılacaktır. bağlantıları.

Uyarılar

Bazı işletim sistemi / tarayıcı kombinasyonları SNI'yi desteklemez (aşağıya bakınız), bu nedenle SNI kullanımı tüm durumlar için uygun değildir. Bu tür sistem / tarayıcı kombinasyonlarını hedefleyen sitelerin SNI'den vazgeçmesi ve her sanal ana bilgisayar için benzersiz IP adresleri kullanmaya devam etmesi gerekir.

Özellikle, Windows XP'deki Internet Explorer sürümü SNI'yi desteklememektedir. Bu kombinasyon, İnternet trafiğinin hala önemli (ancak giderek azaldığı; Aralık 2012'de İnternet trafiğinin yaklaşık% 16'sı) İnternet trafiğinin bir bölümünü temsil ettiğinden, bu kullanıcı popülasyonlarını hedefleyen bir site için SNI uygun değildir.

Destek

Yaygın olarak kullanılan birçok yazılım paketi SNI'yi desteklemektedir.

(Bu listedeki ihmal, mutlaka destek eksikliği anlamına gelmez; bu, ne kadar yazabileceğimin bir sınırı olduğu anlamına gelir veya bir aramada bilgileri hızlıca bulamadım. Yazılım paketiniz listede yoksa, arama yapın. çünkü adı artı sni, destek olup olmadığını ve nasıl kurulacağını açıklamalıdır.)

Kütüphane Desteği

Çoğu paket, SSL / TLS desteği sağlamak için harici bir kütüphaneye dayanır.

• GNU TLS
• JSSE (Oracle Java) 7 veya daha üstü, yalnızca bir istemci olarak
• libcurl 7.18.1 veya daha yüksek
• NSS 3.1.1 veya daha üstü
• OpenSSL 0.9.8j veya daha yüksek
  • OpenSSL 0.9.8f veya daha üstü, configure bayraklı
• Qt 4.8 veya daha yüksek

Sunucu Desteği

Popüler sunucu yazılımının en güncel sürümleri SNI'yi destekler. Bunların çoğu için kurulum talimatları mevcuttur:

• Apache 2.2.12 veya daha yüksek
• Apache Traffic Server 3.2.0 veya daha yüksek
• Cherokee
• HAProxy 1.5 veya daha yüksek
• IIS 8.0 veya daha yüksek
• lighttpd 1.4.24 veya daha yüksek
• LiteSpeed ​​4.1 veya daha yüksek
• nginx 0.5.32 veya daha yüksek

Müşteri Desteği

Mevcut web tarayıcılarının çoğu ve komut satırı kullanıcı aracıları SNI'yi destekler.

Masaüstü

• Chrome 5 veya daha üstü
  • Windows XP'de Chrome 6 veya üzeri
• Firefox 2 veya üstü
• Internet Explorer 7 veya üzeri, Windows Vista / Server 2008 veya üzeri işletim sistemi
  • Windows XP'deki Internet Explorer, IE sürümünden bağımsız olarak SNI'yi desteklemiyor
• Konqueror 4.7 veya daha yüksek
• Opera 8 veya daha üstü (TLS 1.1'in çalışması için etkin olabilir)
• Windows Vista / Server 2008 veya üzeri sürümlerde Safari 3.0 veya Mac OS X 10.5.6 veya üst sürümlerinde

seyyar

• 3.0 Honeycomb veya daha yüksek sürümlerde Android Tarayıcı
• iOS 4 veya üzeri sürümlerde iOS Safari
• Windows Phone 7 veya üstü

Komut satırı

• cURL 7.18.1 veya daha yüksek
• 1.14 veya üstü wget (Dağıtımlar SNI desteği için bir yamayı desteklemiş olabilir)

Destek yok

• BlackBerry Tarayıcı
• Windows XP'de Internet Explorer (herhangi bir sürüm)

(Not: Bu cevap için bazı bilgiler Wikipedia'dan alınmıştır .)

Sorun:

Bir web istemcisi ve bir web sunucusu HTTPS üzerinden birbirleriyle konuştuğunda, olması gereken ilk şey güvenli el sıkışmadır.

İşte böyle bir el sıkışma basitleştirilmiş bir örnek:

Bu HTTP ise ve HTTPS olmasaydı, müşterinin göndereceği ilk şey şunun gibi olurdu:

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

Bu, tek bir IP adresinde birden fazla sanal ana bilgisayarı mümkün kıldı; çünkü sunucu, müşterinin tam olarak hangi alana erişmek istediğini, yani example.com'u biliyor.

HTTPS farklı. Daha önce de söylediğim gibi, el sıkışma her şeyden önce gelir. Yukarıda gösterilen el sıkışmasının üçüncü adımına bakarsanız (Sertifika), sunucunun el sıkışmasının bir parçası olarak müşteriye bir sertifika sunması gerekir, ancak müşterinin erişmeye çalıştığı etki alanı adına dair hiçbir ipucu yoktur. Sunucunun sahip olduğu tek seçenek, her defasında aynı sertifikayı, varsayılan sertifikasını göndermektir.

Web sunucunuzda sanal ana bilgisayarlar ayarlamaya devam edebilirsiniz ancak sunucu her istemciye her zaman aynı sertifikayı gönderir. Sunucunuzda example.com ve example.org web sitelerini barındırmaya çalıştıysanız, bir istemci bir HTTPS bağlantısı istediğinde, sunucu her zaman example.com için sertifikayı gönderir. Böylece bir müşteri kurulu bir HTTPS bağlantısı üzerinden example.org talep ettiğinde, bu olur:

Bu sorun, HTTPS üzerinden sunucu alabileceğiniz alan adedini her IP adresi için bir taneyle sınırlandırır.

Çözüm:

Bu sorunu çözmenin en kolay yolu, müşterinin sunucuya el sıkışma sırasında hangi alana erişmek istediğini söylemesidir . Bu şekilde sunucu doğru sertifikayı sunabilir.

Bu tam olarak ne SNI veya Sunucu Adı Göstergesi yapar.

SNI ile istemci, ilk el sıkışma diyagramındaki "Müşteri Merhaba" adımındaki ilk iletinin bir parçası olarak erişmek istediği sunucu adını gönderir.

Bazı eski web tarayıcıları SNI'yi desteklememektedir. Örneğin, Windows XP'de SNI desteği olan tek bir Internet Explorer sürümü yoktur . SNI sanal ana bilgisayarlarını kullanan bir sunucudaki HTTPS üzerinden bir kaynağa erişirken, tarayıcının bir uyarı veya hata göstermesine neden olabilecek genel bir sertifika sunulur.

Burada problemin ve çözümün arkasındaki prensibi açıklamak için işleri basitleştirdim. Daha teknik bir açıklama isterseniz, wikipedia sayfası veya RFC 6066 iyi bir başlangıç ​​noktası olabilir. Ayrıca, Wikipedia'da SNI'yi destekleyen sunucular ve tarayıcılar için güncel bir liste de bulabilirsiniz.

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

İstemci tarayıcısının da SNI'yi desteklemesi gerekir. İşte yapan bazı tarayıcılar:

* 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 

Ad tabanlı vhost'ların HTTPS üzerinden çalışması için sunucu adı göstergesi (RFC6066) TLS uzantısı gerekir.

Bu uzantı yaygın bir şekilde uygulanmaktadır ve şu anki yazılımla ilgili herhangi bir sorunla henüz karşı karşıya gelmedim, ancak SNI'ye bağlıysanız bazı istemcilerin (onu desteklemeyenlerin) varsayılan sitenize yönlendirilme olasılığı vardır.