C’est une question canonique sur l’hébergement de plusieurs sites Web SSL sur la même adresse IP.

J'avais l'impression que chaque certificat SSL nécessitait sa propre combinaison unique adresse IP / port. Mais la réponse à une question précédente que j’ai posée va à l’encontre de cette affirmation.

En utilisant les informations de cette question, j’ai pu faire fonctionner plusieurs certificats SSL sur la même adresse IP et sur le port 443. Je suis très confus quant à la raison pour laquelle cela fonctionne compte tenu de la supposition ci-dessus et renforcé par d’autres que chaque site Web de domaine SSL sur le le même serveur nécessite son propre IP / Port.

Je soupçonne que j'ai fait quelque chose de mal. Peut-on utiliser plusieurs certificats SSL de cette façon?

Pour obtenir les informations les plus récentes sur Apache et SNI, y compris des RFC spécifiques à HTTP, consultez le wiki d'Apache.

FYsI: "Plusieurs certificats SSL (différents) sur une IP" vous est présenté par la magie de la mise à niveau TLS. Cela fonctionne avec les nouveaux serveurs Apache (2.2.x) et les navigateurs raisonnablement récents (je ne connais pas les versions par cœur).

La RFC 2817 (mise à niveau vers TLS dans HTTP / 1.1) contient les détails sanglants, mais elle fonctionne pour beaucoup de personnes (si ce n’est la majorité).
Vous pouvez cependant reproduire l'ancien comportement funky à l'aide de la s_clientcommande openssl (ou de tout navigateur "assez ancien").

Modifier pour ajouter: apparemment, curlpeut vous montrer ce qui se passe ici mieux que 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.

Oui, mais il y a des mises en garde.

Ceci est accompli par l’intermédiaire de l’indication du nom du serveur, une extension de Transport Layer Security.

Qu'est-ce que l'indication du nom du serveur?

Indication du nom du serveur ( RFC 6066 ; RFC 4366 , RFC 3546 obsolète ) est une extension de Transport Layer Security qui permet au client d'indiquer au serveur le nom de l'hôte qu'il tente d'atteindre.

SNI est compatible avec TLS 1.0 et supérieur selon les spécifications, mais les implémentations peuvent varier (voir ci-dessous). Il ne peut pas être utilisé avec SSL. Par conséquent, une connexion doit négocier le protocole TLS (voir l’ annexe E du RFC 4346 ) pour que le SNI soit utilisé. Cela se produit généralement automatiquement avec les logiciels pris en charge.

Pourquoi le SNI est-il nécessaire?

Dans une connexion HTTP normale , le navigateur informe le serveur du nom d'hôte du serveur auquel il tente de parvenir à l'aide de l'en- Host:tête. Cela permet à un serveur Web sur une seule adresse IP de servir du contenu pour plusieurs noms d'hôte, généralement appelé hébergement virtuel basé sur un nom .

L'alternative consiste à attribuer des adresses IP uniques à chaque nom d'hôte Web à desservir. Cela se faisait généralement au tout début du Web, avant que l’on sache généralement que les adresses IP s’épuiseraient et que les mesures de conservation seraient mises en place. C’est toujours le cas pour les hôtes virtuels SSL (n’utilisant pas SNI).

Comme cette méthode de transmission du nom d'hôte nécessite que la connexion soit déjà établie, elle ne fonctionne pas avec les connexions SSL / TLS. Au moment de la configuration de la connexion sécurisée, le serveur Web doit déjà savoir quel nom d’hôte il servira au client, car le serveur Web lui-même est en train de configurer la connexion sécurisée.

SNI résout ce problème en demandant au client de transmettre le nom d'hôte dans le cadre de la négociation TLS, de sorte que le serveur sache déjà quel hôte virtuel doit être utilisé pour desservir la connexion. Le serveur peut ensuite utiliser le certificat et la configuration pour le bon hôte virtuel.

Pourquoi ne pas utiliser différentes adresses IP?

L'en- Host:tête HTTP a été défini pour permettre à plusieurs hôtes Web d'être desservis à partir d'une seule adresse IP en raison de la pénurie d'adresses IPv4, reconnue comme un problème dès le milieu des années 90. Dans les environnements d'hébergement Web partagés, des centaines de sites Web uniques et non liés peuvent être servis à l'aide d'une seule adresse IP de cette manière, en économisant l'espace d'adressage.

Les environnements d'hébergement partagé ont alors découvert que le plus gros consommateur d'espace d'adressage IP était la nécessité pour les sites Web sécurisés de disposer d'adresses IP uniques, d'où la nécessité de SNI en tant que mesure décisive sur la voie du protocole IPv6. Aujourd'hui, il est parfois difficile d'obtenir aussi peu que 5 adresses IP (/ 29) sans justification significative, ce qui entraîne souvent des retards de déploiement.

Avec l'avènement de l'IPv6, de telles techniques de conservation des adresses ne sont plus nécessaires, puisqu'un seul hôte peut se voir attribuer plus d'adresses IPv6 que tout l'Internet actuel, mais ces techniques seront probablement encore utilisées dans le futur pour la maintenance des anciens services IPv4. les liaisons.

Mises en garde

Certaines combinaisons système d'exploitation / navigateur ne supportant pas SNI (voir ci-dessous), l'utilisation de SNI ne convient donc pas à toutes les situations. Les sites ciblant de telles combinaisons système / navigateur devraient renoncer à SNI et continuer à utiliser des adresses IP uniques pour chaque hôte virtuel.

Il convient de noter qu'aucune version d'Internet Explorer sur Windows XP ne prend en charge SNI. Comme cette combinaison représente toujours une portion significative (mais en diminution constante: environ 16% du trafic Internet en décembre 2012 selon NetMarketShare), le SNI serait inapproprié pour un site ciblant ces populations d'utilisateurs.

Soutien

De nombreux progiciels couramment utilisés prennent en charge SNI.

(Omission de cette liste ne signifie pas nécessairement un manque de support; cela signifie qu'il y avait une limite à la quantité que je pouvais taper, ou je ne pouvais pas trouver rapidement les informations dans une recherche. Si votre progiciel n'est pas répertorié, la recherche pour son nom, plus snidevrait révéler si le support existe et comment le configurer.)

Soutien de la bibliothèque

La plupart des packages dépendent d'une bibliothèque externe pour assurer la prise en charge de SSL / TLS.

• GNU TLS
• JSSE (Oracle Java) 7 ou supérieur, uniquement en tant que client
• libcurl 7.18.1 ou supérieur
• NSS 3.1.1 ou supérieur
• OpenSSL 0.9.8j ou supérieur
  • OpenSSL 0.9.8f ou supérieur, avec les drapeaux configure
• Qt 4.8 ou supérieur

Support serveur

La plupart des versions actuelles des logiciels de serveur courants prennent en charge SNI. Les instructions d'installation sont disponibles pour la plupart d'entre elles:

• Apache 2.2.12 ou supérieur
• Apache Traffic Server 3.2.0 ou supérieur
• Cherokee
• HAProxy 1.5 ou supérieur
• IIS 8.0 ou supérieur
• lighttpd 1.4.24 ou supérieur
• LiteSpeed ​​4.1 ou supérieur
• nginx 0.5.32 ou supérieur

Support client

La plupart des navigateurs Web et des agents utilisateurs de ligne de commande actuels prennent en charge SNI.

Bureau

• Chrome 5 ou supérieur
  • Chrome 6 ou supérieur sur Windows XP
• Firefox 2 ou supérieur
• Internet Explorer 7 ou supérieur, fonctionnant sous Windows Vista / Server 2008 ou supérieur
  • Internet Explorer sous Windows XP ne prend pas en charge SNI, quelle que soit la version d'IE
• Konqueror 4.7 ou supérieur
• Opera 8 ou supérieur (peut nécessiter que TLS 1.1 soit activé pour fonctionner)
• Safari 3.0 sur Windows Vista / Server 2008 ou version ultérieure ou Mac OS X 10.5.6 ou version ultérieure

Mobile

• Navigateur Android sur 3.0 Honeycomb ou supérieur
• iOS Safari sur iOS 4 ou supérieur
• Windows Phone 7 ou supérieur

Ligne de commande

• curl 7.18.1 ou supérieur
• wget 1.14 ou supérieur (les distributions peuvent avoir rétroporté un correctif pour le support SNI)

Pas de support

• Navigateur BlackBerry
• Internet Explorer (toute version) sur Windows XP

(Remarque: certaines informations pour cette réponse ont été obtenues à partir de Wikipedia .)

Le problème:

Lorsqu'un client Web et un serveur Web se parlent via HTTPS, la première chose à faire est la négociation sécurisée.

Voici un exemple simplifié d'une telle poignée de main:

S'il s'agissait de HTTP et non de HTTPS, la première chose que le client aurait envoyée aurait été quelque chose comme ceci:

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

Cela a rendu possible plusieurs hôtes virtuels sur une seule adresse IP, car le serveur sait exactement à quel domaine le client veut accéder, à savoir exemple.com.

HTTPS est différent. Comme je l'ai dit plus tôt, la poignée de main vient avant tout le reste. Si vous examinez la troisième étape de la négociation illustrée ci-dessus (Certificat), le serveur doit présenter un certificat au client dans le cadre de la négociation, mais n'a aucune idée du nom de domaine auquel le client tente d'accéder. La seule option dont dispose le serveur est d'envoyer le même certificat à chaque fois, son certificat par défaut.

Vous pouvez toujours configurer des hôtes virtuels sur votre serveur Web, mais le serveur enverra toujours le même certificat à chaque client. Si vous tentez d'héberger les sites Web exemple.com et exemple.org sur votre serveur, celui-ci enverra toujours le certificat à exemple.com lorsqu'un client demande une connexion HTTPS. Ainsi, lorsqu'un client demande example.org via une connexion HTTPS établie, ceci se produit:

Ce problème limite effectivement le nombre de domaines que vous pouvez serveur via HTTPS à un par adresse IP.

La solution:

Le moyen le plus simple de résoudre ce problème consiste pour le client à indiquer au serveur le domaine auquel il souhaite accéder au cours de la négociation . De cette façon, le serveur peut servir le bon certificat.

C’est exactement ce que fait SNI ou Indication du nom du serveur.

Avec SNI, le client envoie le nom du serveur auquel il souhaite accéder dans le cadre du premier message, l’étape "Client Hello" dans le schéma de négociation ci-dessus.

Certains navigateurs Web plus anciens ne prennent pas en charge SNI. Par exemple, sous Windows XP, aucune version d'Internet Explorer ne prend en charge SNI. Lors de l'accès à une ressource via HTTPS sur un serveur utilisant des hôtes virtuels SNI, un certificat générique vous sera présenté, ce qui peut amener le navigateur à afficher un avertissement ou une erreur.

J'ai simplifié les choses ici pour expliquer le principe du problème et de sa solution. Si vous souhaitez une explication plus technique, la page wikipedia ou RFC 6066 peut constituer un bon point de départ. Vous pouvez également trouver une liste actualisée des serveurs et navigateurs prenant en charge SNI sur wikipedia.

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

Le navigateur client doit également prendre en charge SNI. Voici quelques navigateurs qui font:

* 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'extension TLS d'indication de nom de serveur (RFC6066) est requise pour que les hôtes virtuels basés sur des noms fonctionnent sur HTTPS.

L'extension est largement mis en œuvre et je dois encore rencontrer des problèmes avec les logiciels actuels, mais il y a une chance que certains clients (ceux qui ne le supporte pas) seront acheminés vers votre site par défaut si vous dépendez SNI.