Est-il techniquement possible de configurer deux certificats SSL différents pour le même domaine?
Disons que j'ai ces URL:
Je veux que le premier soit servi avec un certificat SSL commercial validé par domaine et le second avec un certificat SSL à validation étendue. Est-ce techniquement possible? Est-il pris en charge par les normes et les navigateurs SSL/TLS (et HTTPS?)?
Je ne demande en aucun cas si c'est même une bonne configuration (je choisirais l'EV pour tout le domaine), j'ai juste besoin de savoir si cette configuration est supportée. J'apprécierais vraiment les références aux normes.
Oui et non.
Il est possible d'avoir plusieurs certificats qui ont tous le même nom de domaine. Vous pouvez avoir un certificat exemple.org Comodo et un certificat exemple.org Entrust, tous deux valides et officiels, aucun problème. Je crois que certains équilibreurs de charge feront tourner celui qui est utilisé sur une base par connexion, mais uniquement de manière circulaire.
Le Non est que vous demandez si vous pouvez sélectionner le certificat à utiliser en fonction de l'URI (/ vs/chemin critique). Le problème est que l'URI n'est disponible qu'après avoir cloué la connexion SSL à l'aide de l'un des deux certificats. Vous ne pouvez donc pas vraiment choisir le certificat à utiliser en fonction des informations que vous ne pouvez avoir qu'après avoir choisi le certificat.
Maintenant, je ne vais pas dire à 100% que c'est impossible. Avec Apache, par exemple, vous pouvez définir la configuration SSLCipherSuite par répertoire, donc je ne serais pas surpris s'il y avait certains moyen de forcer un renégociation qui impliquerait un nouveau cert. Mais je soupçonne plutôt que ce n'est pratiquement pas implémenté même si c'est théoriquement possible. (Apache SSLCertificate * est par serveur ou par hôte, pas par répertoire).
Annexe : Réflexions lors de la renégociation
Avis de non-responsabilité: je n'ai rien fait de tout cela, c'est une interprétation profane des RFC et d'autres documents. Des dizaines de personnes ici sont bien plus qualifiées pour commenter que moi.
Je vais regarder TLS 1.2 car il est soigneusement décrit dans RFC 5246 .
Section 7.4.1.1, "Le message HelloRequest PEUT être envoyé par le serveur à tout moment." Cela devrait inciter le client à renégocier la connexion. (Le client PEUT ignorer cette demande, et le serveur PEUT interrompre la connexion si le client ignore la demande trop longtemps.)
Une renégociation ressemble beaucoup à une négociation initiale, bien qu'elle puisse transmettre certaines informations de la négociation précédente pour essayer de lisser le chemin (par exemple, voici le chiffre que nous avons convenu la dernière fois). Ainsi, le client envoie un ClientHello , puis le serveur envoie un ServerHello , alors le serveur envoie un Certificat de serveur (7.4.2).
Donc, ma lecture de la RFC est que, oui, un serveur peut forcer la renégociation d'une connexion, y compris la sélection d'un certificat de serveur différent.
Je vais être honnête avec vous, je ne sais pas si vous trouverez des logiciels existants qui feront ce que vous voulez faire. Je vous suggère de commencer à jouer avec Perl Crypto :: OpenSSL ou la bibliothèque ssl de Python pour voir si vous pouvez le tester.
Nan. Aucun serveur Web ne peut prendre en charge cette fonctionnalité; pas maintenant, jamais. Voici pourquoi:
HTTPS suit ces étapes dans cet ordre:
- Le client se connecte au serveur
- Négociation SSL/TLS (comprend l'échange de certificats, la vérification des certificats et la configuration du cryptage)
- Le client envoie une demande (inclut le nom d'hôte du serveur, le chemin, les cookies, etc.)
- Le serveur renvoie la réponse (inclut les en-têtes de réponse, le contenu, etc.)
Notez que l'étape 2 ci-dessus se produit avant l'étape 3. C'est-à-dire que tout le cryptage est totalement terminé avant que le navigateur ne dise au serveur quelle URL il recherche. Cela signifie que lorsque le serveur sélectionne un certificat SSL à utiliser, il ne sait pas encore quel sera le chemin URL. Étant donné que ces informations ne sont pas disponibles à ce stade, elles ne peuvent pas prendre en compte la décision du certificat à utiliser.
Notez également que le nom d'hôte est envoyé au serveur à l'étape 3, c'est pourquoi chaque certificat est généralement installé sur des adresses IP uniques; le serveur utilise l'adresse IP pour déterminer le certificat à présenter. De nouvelles versions de SSL/TLS ont ajouté une extension appelée Server Name Identification pour permettre au client de spécifier le nom d'hôte pendant la négociation TLS, mais cela ne fonctionne que pour les noms d'hôte.
Aucune disposition n'autorise la sélection de certificats en fonction du chemin URL, et il n'y en aura jamais, car cela impliquerait que le chemin URL doive être envoyé au serveur non chiffré dans le cadre de la sélection de certificats. Et l'envoi de l'URL non crypté serait inacceptable pour une page sécurisée.
Je pense que peut être possible en utilisant le déchargement SSL, l'inspection approfondie des paquets et la renégociation TLS. Cependant, si vous renégociez Google TLS, les 20 premiers résultats concerneront les vulnérabilités de renégociation - donc si vous le faites, vous risquez de rendre votre site moins sécurisé, pas plus.
D'un autre côté, si votre schéma était comme ceci:
https://criticalpath.example.org/
ce serait assez banal. Vous devez simplement router ces deux domaines vers différentes IP internes et lier les IP à différents certificats.