Questa è una domanda canonica sull'hosting di più siti Web SSL sullo stesso IP.

Avevo l'impressione che ogni certificato SSL richiedesse la propria combinazione unica di indirizzo IP / porta. Ma la risposta a una domanda precedente che ho pubblicato è in contrasto con questa affermazione.

Usando le informazioni di quella domanda, sono stato in grado di ottenere più certificati SSL per funzionare sullo stesso indirizzo IP e sulla porta 443. Sono molto confuso sul perché questo funzioni dato il presupposto sopra e rafforzato da altri che ogni sito Web del dominio SSL sul lo stesso server richiede il proprio IP / porta.

Sono sospettoso di aver fatto qualcosa di sbagliato. È possibile utilizzare più certificati SSL in questo modo?

Per le informazioni più aggiornate su Apache e SNI, inclusi ulteriori RFC specifici per HTTP, fare riferimento al Wiki di Apache

FYsI: "Più certificati SSL (diversi) su un IP" sono offerti dalla magia dell'aggiornamento TLS. Funziona con i nuovi server Apache (2.2.x) e browser abbastanza recenti (non conosco le versioni dalla parte superiore della mia testa).

RFC 2817 (aggiornamento a TLS in HTTP / 1.1) ha i dettagli cruenti, ma fondamentalmente funziona per molte persone (se non la maggioranza).
Puoi riprodurre il vecchio comportamento funky con il s_clientcomando di openssl (o qualsiasi browser "abbastanza vecchio").

Modifica per aggiungere: apparentemente curlpuò mostrarti cosa sta succedendo qui meglio di 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.

Sì, ma ci sono alcuni avvertimenti.

Ciò avviene tramite Indicazione nome server, un'estensione di Transport Layer Security.

Che cos'è l'indicazione del nome del server?

L'indicazione del nome del server ( RFC 6066 ; obsoleto RFC 4366 , RFC 3546 ) è un'estensione di Transport Layer Security che consente al client di comunicare al server il nome dell'host che sta tentando di raggiungere.

SNI è compatibile con TLS 1.0 e versioni successive in base alle specifiche, ma le implementazioni possono variare (vedere di seguito). Non può essere utilizzato con SSL, quindi una connessione deve negoziare TLS (vedere l' appendice E RFC 4346 ) per poter utilizzare SNI. Questo generalmente avviene automaticamente con il software supportato.

Perché è necessario SNI?

In una normale connessione HTTP , il browser informa il server del nome host del server che sta tentando di raggiungere utilizzando l' Host:intestazione. Ciò consente a un server Web su un singolo indirizzo IP di servire contenuto per più nomi host, comunemente noto come hosting virtuale basato su nomi .

L'alternativa è assegnare indirizzi IP univoci per ciascun nome host Web da offrire. Questo è stato comunemente fatto nei primissimi giorni del Web, prima che fosse noto che gli indirizzi IP si sarebbero esauriti e che le misure di conservazione iniziassero, e che è ancora fatto in questo modo per gli host virtuali SSL (non usando SNI).

Poiché questo metodo di trasmissione del nome host richiede che la connessione sia già stabilita, non funziona con le connessioni SSL / TLS. Quando viene stabilita la connessione sicura, il server Web deve già sapere quale nome host servirà al client, poiché il server Web stesso sta configurando la connessione protetta.

SNI risolve questo problema facendo in modo che il client trasmetta il nome host come parte della negoziazione TLS, in modo che il server sia già a conoscenza dell'host virtuale da utilizzare per la connessione. Il server può quindi utilizzare il certificato e la configurazione per l'host virtuale corretto.

Perché non usare indirizzi IP diversi?

L' Host:intestazione HTTP è stata definita per consentire a più host Web di essere serviti da un singolo indirizzo IP a causa della carenza di indirizzi IPv4, riconosciuto come un problema già dalla metà degli anni '90. In ambienti di hosting Web condivisi, è possibile servire centinaia di siti Web unici e non correlati utilizzando un singolo indirizzo IP in questo modo, conservando lo spazio degli indirizzi.

Gli ambienti di hosting condiviso hanno quindi scoperto che il più grande consumatore di spazio degli indirizzi IP era la necessità che i siti Web sicuri avessero indirizzi IP univoci, creando la necessità di SNI come misura di stop-gap sulla strada verso IPv6. Oggi a volte è difficile ottenere fino a 5 indirizzi IP (/ 29) senza una giustificazione significativa, causando spesso ritardi nella distribuzione.

Con l'avvento di IPv6, tali tecniche di conservazione degli indirizzi non sono più necessarie, poiché a un singolo host possono essere assegnati più indirizzi IPv6 rispetto a quelli dell'intera Internet oggi, ma le tecniche saranno probabilmente ancora utilizzate in futuro per servire l'IPv4 legacy connessioni.

Avvertenze

Alcune combinazioni di sistema operativo / browser non supportano SNI (vedere di seguito), quindi l'utilizzo di SNI non è appropriato per tutte le situazioni. I siti destinati a tali combinazioni di sistema / browser dovrebbero rinunciare a SNI e continuare a utilizzare indirizzi IP univoci per ciascun host virtuale.

Di particolare nota, nessuna versione di Internet Explorer su Windows XP supporta SNI. Poiché questa combinazione rappresenta ancora una porzione significativa (ma in costante calo; circa il 16% del traffico Internet nel dicembre 2012 secondo NetMarketShare) del traffico Internet, SNI sarebbe inappropriato per un sito destinato a queste popolazioni di utenti.

Supporto

Molti pacchetti software di uso comune, ma non tutti, supportano SNI.

(L'omissione da questo elenco non significa necessariamente mancanza di supporto; significa che c'era un limite a quanto potevo digitare o non riuscivo a trovare rapidamente le informazioni in una ricerca. Se il tuo pacchetto software non è elencato, la ricerca per il suo nome plus snidovrebbe rivelare se esiste supporto e come impostarlo.)

Supporto per la biblioteca

La maggior parte dei pacchetti dipende da una libreria esterna per fornire supporto SSL / TLS.

• GNU TLS
• JSSE (Oracle Java) 7 o versioni successive, solo come client
• libcurl 7.18.1 o successivo
• NSS 3.1.1 o versioni successive
• OpenSSL 0.9.8j o successivo
  • OpenSSL 0.9.8f o superiore, con flag di configurazione
• Qt 4.8 o superiore

Supporto server

La maggior parte delle versioni attuali del popolare software server supporta SNI. Le istruzioni di installazione sono disponibili per la maggior parte di questi:

• Apache 2.2.12 o successivo
• Apache Traffic Server 3.2.0 o versione successiva
• Cherokee
• HAProxy 1.5 o successivo
• IIS 8.0 o versioni successive
• lighttpd 1.4.24 o successivo
• LiteSpeed ​​4.1 o versioni successive
• nginx 0,5,32 o superiore

Assistenza clienti

La maggior parte dei browser Web e degli user agent della riga di comando supportano SNI.

Desktop

• Chrome 5 o versioni successive
  • Chrome 6 o versioni successive su Windows XP
• Firefox 2 o versioni successive
• Internet Explorer 7 o versioni successive, in esecuzione su Windows Vista / Server 2008 o versioni successive
  • Internet Explorer su Windows XP non supporta SNI indipendentemente dalla versione di IE
• Konqueror 4.7 o versioni successive
• Opera 8 o versione successiva (potrebbe essere necessario abilitare TLS 1.1 per funzionare)
• Safari 3.0 su Windows Vista / Server 2008 o versione successiva o Mac OS X 10.5.6 o versione successiva

Mobile

• Browser Android su Honeycomb 3.0 o versione successiva
• iOS Safari su iOS 4 o versioni successive
• Windows Phone 7 o versioni successive

Riga di comando

• cURL 7.18.1 o successivo
• wget 1.14 o versione successiva (le distribuzioni potrebbero aver eseguito il backport di una patch per il supporto SNI)

Senza supporto

• BlackBerry Browser
• Internet Explorer (qualsiasi versione) su Windows XP

(Nota: alcune informazioni per questa risposta sono state ottenute da Wikipedia .)

Il problema:

Quando un client Web e un server Web parlano tra loro tramite HTTPS, la prima cosa che deve accadere è l'handshake sicuro.

Ecco un esempio semplificato di tale stretta di mano:

Se fosse HTTP e non HTTPS, la prima cosa che il client avrebbe inviato sarebbe stata qualcosa del genere:

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

Ciò ha reso possibili più host virtuali su un singolo indirizzo IP, poiché il server conosce esattamente a quale dominio desidera accedere il client, vale a dire esempio.com.

HTTPS è diverso. Come ho detto prima, la stretta di mano viene prima di ogni altra cosa. Se si osserva il terzo passaggio dell'handshake illustrato sopra (Certificato), il server deve presentare un certificato al client come parte dell'handshake, ma non ha idea del nome di dominio a cui il client sta tentando di accedere. L'unica opzione che il server ha è di inviare ogni volta lo stesso certificato, il suo certificato predefinito.

Potresti comunque impostare host virtuali sul tuo server web, ma il server invierebbe sempre lo stesso certificato a ciascun client. Se si tenta di ospitare sia i siti Web example.com che example.org sul server, il server invierà sempre il certificato per example.com quando un client richiede una connessione HTTPS. Quindi, quando un client richiede example.org su una connessione HTTPS stabilita, ciò accade:

Questo problema limita efficacemente il numero di domini che è possibile server su HTTPS a uno per indirizzo IP.

La soluzione:

Il modo più semplice per risolvere questo problema è per il client comunicare al server a quale dominio desidera accedere durante l'handshake . In questo modo il server può fornire il certificato corretto.

Questo è esattamente ciò che fa SNI , o Server Name Indication.

Con SNI, il client invia il nome del server a cui desidera accedere come parte del primo messaggio, il passaggio "Client Hello" nel diagramma di handshake sopra.

Alcuni browser Web meno recenti non supportano SNI. Ad esempio, su Windows XP non esiste un'unica versione di Internet Explorer che supporti SNI. Quando si accede a una risorsa tramite HTTPS su un server che utilizza host virtuali SNI, verrà presentato un certificato generico, che può causare la visualizzazione di un avviso o un errore nel browser.

Ho semplificato le cose qui per spiegare semplicemente il principio alla base del problema e della soluzione. Se desideri una spiegazione più tecnica, la pagina di Wikipedia o RFC 6066 potrebbe servire come buoni punti di partenza. Puoi anche trovare un elenco aggiornato di server e browser che supportano SNI su wikipedia

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

Il browser client deve inoltre supportare SNI. Ecco alcuni browser che lo fanno:

* 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 

L'estensione TLS per l'indicazione del nome del server (RFC6066) è necessaria affinché i vhosts basati sul nome funzionino su HTTPS.

L'estensione è ampiamente implementata e devo ancora riscontrare problemi con il software attuale, ma è possibile che alcuni client (quelli che non lo supportano) vengano indirizzati al tuo sito predefinito se dipendi da SNI.