Re: Certificats SSL
On Wed, Dec 03, 2008 at 06:16:38PM +0100,
François TOURDE <fra-duf-no-spam@tourde.org> 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.
Reply to: