Merci Stéphane, je vais vérifier si mon CA accepte l'option Subject Alternative Name lors la certification.
Le 4 décembre 2008 22:11, Stephane Bortzmeyer <[EMAIL PROTECTED]> a écrit : > On Wed, Dec 03, 2008 at 06:16:38PM +0100, > François TOURDE <[EMAIL PROTECTED]> wrote > a message of 26 lines which said: > > > Si si, c'est faisable. Je sais plus où j'avais vu de la doc > > là-dessus, > > Ici :-) > > > Authentifier des serveurs Internet avec X.509 lorsqu'ils ont la même > adresse IP > > http://www.bortzmeyer.org/auth-x509-plusieurs-noms.html > > Première rédaction de cet article le 4 Décembre 2008 > > ---------------------------- > > > On lit souvent qu'il n'est pas possible d'avoir plusieurs serveurs > Internet sur la même adresse IP lorsqu'ils sont authentifiés par un > certificat X.509. Il faudrait donc donner une adresse IP à chacun. > Cette affirmation a des origines réalistes mais est sans doute trop > stricte aujourd'hui. > > Dans un protocole comme HTTPS, le nom du serveur est transmis une fois > la session TLS établie. Il est donc a priori trop tard à ce moment pour > choisir un autre certificat. D'où le mème « Un seul certificat par > adresse IP ». En fait, il est possible d'avoir une seule adresse IP et > néanmoins un certificat différent par "Virtual Host" Apache, même si > les méthodes existantes ont quelques limites. > > Il existe trois méthodes pour HTTPS (toutes ne sont pas forcément > applicables aux autres protocoles) : > * La commande HTTP STARTTLS (RFC 2817) qui permet de transmettre le nom > du serveur avant la négociation TLS. > * L'extension X.509 "Subject Alternative Name" (RFC 2459) qui permet de > mettre plusieurs noms dans un certificat. Le client sera alors content > si un des noms correspond. > * L'extension X.509 "Server Name Indication" (SNI) (RFC 4366) qui > permet au client d'indiquer le nom du serveur dans la négociation TLS. > > Chacune a ses forces et ses faiblesses et des domaines où elle est > meilleure que les autres. > > La première, STARTTLS, normalisée dans le RFC 2817, est bien décrite > par Pierre Beyssac dans « HTTP et TLS, la RFC méconnue... > (http://signal.eu.org/blog/2007/09/07/http-et-tls-la-rfc-meconnue/) ». > Très répandue avec des protocoles comme IMAP ou SMTP, elle a un gros > inconvénient pour HTTP : il n'est pas possible d'indiquer dans l'URL > que TLS est obligatoire. Un attaquant sur le chemin, ou bien un serveur > mal configuré, et on retombe sur du HTTP non protégé. > > Mise en œuvre dans Apache depuis la version 2.2, elle n'est présent > dans aucun grand navigateur, pour les raisons expliquées par Mozilla > dans la bogue #276813 > (https://bugzilla.mozilla.org/show_bug.cgi?id=276813). > > Une deuxième méthode est le certificat contenant plusieurs noms. Elle > est possible grâce à l'extension X.509 "Subject Alternative Name", > normalisée dans le RFC 2459. Elle est décrite en détail dans mon > article « Plusieurs noms dans un certificat X.509 > (http://www.bortzmeyer.org/plusieurs-noms-dans-certificat.html) » ou > bien dans celui de Franck Davy, « Apache : Hôtes virtuels et SSL > (mod_ssl) > (http://www.hsc.fr/ressources/breves/ssl_virtualhosts.html.fr) ». En > anglais, on peut lire « "Information about setting up the ApacheServer > to serve multiple HTTPS sites using one IP address > (http://wiki.cacert.org/wiki/CSRGenerator?action=show&redirect=VhostsApa > che)" ». > > Elle fonctionne avec openssl (aussi bien pour générer le certificat que > pour le vérifier) mais il faut que la CA qui signe l'accepte et > j'ignore si les grosses CA ayant pignon sur rue le font ou pas. C'est > la méthode qui semble la plus déployée et donc celle qui apporte le > moins de surprises (CAcert a fait des tests détailles > d'interopérabilité > (http://wiki.cacert.org/wiki/VhostTaskForce#InteroperabilityTest) sur > les variants de cette méthode). > > La troisième méthode repose sur une extension du protocole TLS et non > pas du format X.509. Cette extension, "Server Name Indication" (SNI), > est l'une de celles décrites dans le RFC 4366. Elle envoie le nom du > serveur lors de la négociation TLS. Elle est bien expliquée dans > l'article de Pierre Beyssac « Adieu RFC 2817, bonjour RFC 3546 > (http://signal.eu.org/blog/2008/11/25/adieu-rfc-2817-bonjour-rfc-3546/) > ». > > SNI ("Server Name Indication") ne marche pas avec le module Apache > mod_ssl, il faut utiliser mod_gnutls. Il y a un certificat par "Virtual > Host" et elle ne gère donc pas le cas où un "Virtual Host" a plusieurs > noms, avec la directive ServerAlias. > > Les serveurs HTTP gérés par le département de recherche & développement > de l'AFNIC sont un exemple de déploiement de deux de ces techniques. Le > serveur, un Apache, utilise mod_gnutls, avec un certificat par "Virtual > Host", et peut donc tirer profit de la troisième méthode, SNI. Au cas > où le client ne gère pas l'extension SNI, le certificat par défaut > (celui qui est utilisé dans la directive <VirtualHost _default_:443>) > est un certificat avec plusieurs noms. > > Merci à Pierre Beyssac, Mario Victor-Oscar et Yves Rutschle pour des > informations stimulantes et utiles. > > -- > Lisez la FAQ de la liste avant de poser une question : > http://wiki.debian.org/DebFrFrenchLists > Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et > "Reply-To:" > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > >
