Question Plusieurs domaines SSL sur la même adresse IP et le même port?


C'est un 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 le répondre à une question précédente que j'ai postée est en contradiction avec 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 me doute que j'ai fait quelque chose de mal. Peut-on utiliser plusieurs certificats SSL de cette manière?


107
2018-02-04 22:36


origine


Ce corps Q dit plusieurs certificats et les réponses sont correctes pour cela. Mais le titre dit plusieurs domaines et vous peut avoir plusieurs domaines avec un seul cert (et pas de SNI), voir serverfault.com/questions/126072/… et serverfault.com/questions/279722/… passer également sur security.SX. - dave_thompson_085


Réponses:


Pour obtenir les informations les plus récentes sur Apache et SNI, y compris des RFC spécifiques à HTTP, veuillez vous reporter à la Apache Wiki


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 gens (si ce n’est la majorité).
Vous pouvez reproduire le vieux comportement funky avec openssl s_client commande (ou tout navigateur "assez vieux") cependant.

Modifier pour ajouter: apparemment curl peut 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.

68
2018-02-04 23:46



C'est très utile - Merci! Des informations sur la façon de configurer Apache pour TLS au lieu de SSL? - Josh
Je pense qu’Apache 2.2 doit simplement activer les bits TLS dans sa liste de chiffrement. J'admets que je n'ai jamais vu l'intégralité du bit "Mise à niveau de SSL vers TLS" avant ces deux sites. D'après ce que je comprends de la documentation TLS, négocier ce type de mise à niveau est une situation acceptable (mais inhabituelle) ... - voretaq7
C'est la première fois que je vois ça et j'essaie toujours de me tirer la mâchoire du sol ... - Josh
OK, ma réponse vient de tripler de longueur - Apparemment, curl peut faire les négociations SSLv3 et TLSv1 afin que je puisse montrer l'échec et le succès. J'aimerais avoir un débogueur de protocole à portée de main pour montrer la partie magique cependant. (Également testé et heureux de signaler que le serveur de johnlai2004 nie correctement les connexions SSLv2 :-) - voretaq7
C'est extrêmement utile et j'espère que johnlai2004 accepte votre réponse. Merci beaucoup! - Josh


Oui, mais il y a des mises en garde.

Ceci est accompli par le biais de Server Name Indication, une extension de Transport Layer Security.

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

Indication du nom du serveur (RFC 6066; obsolète RFC 4366, RFC 3546) est une extension de Sécurité de la couche de transport ce 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. Une connexion doit donc négocier TLS (voir RFC 4346 annexe E) pour que 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 normale HTTP connexion, le navigateur informe le serveur du nom d’hôte du serveur qu’il tente d’atteindre en utilisant le Host: entête. Ceci permet à un serveur Web sur une seule adresse IP de servir du contenu pour plusieurs noms d’hôte, ce qui est communément appelé hébergement virtuel nominatif.

L'alternative consiste à attribuer des adresses IP uniques à chaque nom d'hôte Web à desservir. Cela a souvent été fait au tout début du Web, avant que l’on sache généralement que les adresses IP allaient s’épuiser et que les mesures de conservation commençaient. 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 l'établissement de la connexion sécurisée, le serveur Web doit déjà savoir quel nom d'hôte il va servir 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?

Le HTTP Host: L'en-tête 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 constaté 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, ce qui créait le besoin 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 d'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 actuellement, 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 sni devrait 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, seulement 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:

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 pièce 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 auprès de Wikipédia.)


96
2017-08-14 23:05



Bien mieux :-) J'espère que cela finira par donner un score plus élevé que celui actuellement accepté, qui, hormis la dernière édition au sommet, est malheureusement généralement erroné. - Bruno
@Bruno Je ne me plaindrai certainement pas si vous trouvez quelques centaines de personnes pour le faire passer au vote. :) - Michael Hampton♦
La dernière version de BlackBerry Browser (10?) Utilise une version récente de WebKit. Il est donc très probable qu’elle prenne en charge SNI maintenant. - dave1010


Le problème:

Lorsqu'un client Web et un serveur Web se parlent via HTTPS, le tout premier Ce qui doit arriver, c'est la poignée de main sécurisée.

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

tls handshake

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 avez essayé d'héberger les sites Web example.com et example.org sur votre serveur, celui-ci enverra toujours le certificat à example.com lorsqu'un client demande une connexion HTTPS. Ainsi, lorsqu'un client demande example.org via une connexion HTTPS établie, ceci se produit:

enter image description here

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. pendant la poignée de main. De cette façon, le serveur peut servir le bon certificat.

C'est exactement ce que SNIou 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, sur Windows XP, il y a n'est pas une version unique d'Internet Explorer qui a un support pour 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.

enter image description here

J'ai simplifié les choses ici pour expliquer le principe du problème et de sa solution. Si vous souhaitez une explication plus technique, le Wikipédia page ou RFC 6066 pourrait servir de bons points de départ. Vous pouvez également trouver une liste actualisée des serveurs et navigateurs prenant en charge SNI sur Wikipédia


37
2017-08-14 19:13





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 

16
2018-02-05 00:46





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 implémentée et je n'ai encore rencontré aucun problème avec le logiciel actuel, mais il est possible que certains clients (ceux qui ne le prennent pas en charge) soient routés vers votre site par défaut si vous dépendez de SNI.


6
2017-08-14 19:10



En plus de la réponse de Falcon, IIS requiert également certaines modifications spéciales pour que plusieurs sites IIS puissent fonctionner sur la même adresse IP. Vous devez modifier manuellement le fichier de configuration pour le serveur ou utiliser un outil CLI pour apporter les modifications de liaison. L'outil graphique ne peut pas le faire. Dans IIS, il est fait référence à l'attribution de certificats SSL aux en-têtes d'hôte. Apache n'a pas eu le problème depuis un moment. - Brent Pabst
Ah ok, ça éclaircit certains. Comment savoir si un client (navigateur) supporte cela? Par exemple, si je veux vérifier MSIE6, comment puis-je tester cela sans avoir à installer une machine XP virtuelle ou autre? - Luc
@Luc en.wikipedia.org/wiki/NomServeur_Indication#Support - cjc
@ Falcon SNI ne fonctionne pas avec IE sur XP; qui représente encore près du quart des utilisateurs d’Internet de bureau. Je n'appellerais pas cela "largement mis en œuvre" lorsqu'un quart des visiteurs potentiels ne travaillent pas. - Chris S
@MichaelHampton IE utilise la pile de cryptage Windows native pour SSL. XP ne prend pas en charge SNI, donc aucune version d’IE fonctionnant sous XP ne le fait également. IE ne prend en charge que SNI dans Vista et les systèmes d'exploitation plus récents. - Chris S