Et la marmotte ...

Publié le par Peck

Retrouvez la suite sur http://linux-attitude.fr/post/Et-la-marmotte

Niveau
:
Résumé : subjectAltName   

On vous a toujours dit qu'il n'était pas possible de faire des virtualhost en https. En gros vous devriez avoir une ip par site. Mais réveillez vous camarade, on vous ment, on vous spolie ...
En effet tout est possible en informatique, ou presque, c'est juste une question de temps passé à mettre à jour les navigateurs du monde entier.

TLS

Tout d'abord, faut-il vraiment faire du ssl ? C'est une vraie question. En effet, il existe le TLS, "successeur" du SSL qui permet une négociation de la couche de sécurité après une connexion normale. On pourrait donc faire du http sécurisé à la demande sur le port 80. Il existe déja une RFC pour faire du HTTP sur TLS (2817 et 2818) mais pour permettre les virtualhost, il faut une extension supplémentaire (SNI, RFC 3546).
C'est probablement une solution d'avenir, mais :

Certificats SSL


Supposons que vous vouliez donc rester en ssl classique. Alors la bonne solution, celle qui marche pour tous les navigateurs est d'utiliser des certificats avec "SubjAltNames".


Openssl étant codé un peu bizarrement, il ne propose pas de modifier ce paramètre en ligne de commande. Il faut donc modifier le fichier de configuration. Comme nous ne somme pas root et que sous sommes fainéants, nous allons recopier la configuration par défaut dans notre répertoire de travail :

$ cp /etc/ssl/openssl.cnf .
$ vi openssl.cnf

Il faut avoir une section req demandant d'utiliser les extensions et une section spéciale pour l'extension. Et c'est dans cette extention que nous mettrons nos différents virtualhosts.

[ req ]
req_extensions = toto
...

[ toto ]
subjectAltName     = DNS:wiki.toto.fr, DNS:blog.toto.fr


Les différentes entrées doivent se retrouver sur la ligne subjectAltName, séparées par des virgules et précédées de "DNS:". Si ces entrées sont précédées de "critical," cela veut dire qu'un navigateur qui ne comprend pas le subjectAltName devra refuser le certificat.

Générons maintenant notre demande de certificat :

$ openssl req -newkey rsa:1024 -new -out server.csr -config openssl.cnf
$ openssl rsa -in privkey.pem -out server.key

Vérifions que le subjectAltName a bien été pris en compte :

$ openssl req -in server.csr -text


Utilisation

Vous devez maintenant faire signer cette demande par une autorité. Vous avez le choix entre
  • Verisign : il supprimera l'extension
  • Thawte : je ne sais pas
  • Cacert : l'extension sera respectée
  • Votre autorité personnelle

Je ne connais pour l'instant pas de solution permettant d'avoir les subjectAltName certifiés par une autorité disponible dans les navigateurs par défaut.
En attendant, intéressons nous au dernier cas. En effet si vous avez suivi un post récent, vous savez signer cette demande par votre propre certificat. Mais openssl étant vraiment codé très bizarrement, il ne sait pas recopier l'entrée subjectAltName de la demande de certificat. Il faut donc la copier en dur. Openssl étant codé très très bizarrement, "openssl x509" n'utilise pas la même syntaxe que "openssl req" pour passer ces arguments.

Il faut donc créer un fichier de quelques lignes contenant l'extension :
$ cat toto.ext
[ toto ]
subjectAltName     = DNS:wiki.toto.fr, DNS:blog.toto.fr

Et le passer en paramètre lors de la signature :
# voir le billet "garder l'autorité" pour plus de détails
$ openssl x509 -req -in server.csr -out server.crt -CA ca.crt -CAkey ca.key -extfile toto.ext -extensions toto


Et voila, il ne vous reste plus qu'à l'utiliser dans votre serveur web.


Notez que le subjectAltName dans les certificats est supporté par un grand nombre de navigateurs, incluant internet explorer 6, 7 firefox 2, opéra. Le site suivant suggère même que tous les navigateurs le supportent. http://wiki.cacert.org/wiki/VhostTaskForce#head-7236c4e2c9932ef42056b3ff6d367053081887de (lire la dernière colonne)

Publié dans admin

Commenter cet article

annah c. h. 23/10/2007 16:09

L'inconvénient principal de cette méthode (qui fonctionne) est que les noms de tous les virtualhosts SSL apparaissent dans le certificat, et que le client peut en prendre connaissance (ici on sait par exemple que le site gère au-moins wiki.toto.fr et blog.toto.fr qui ne sont pas forcément publics).

Peck 23/10/2007 20:12

En effet. Tant qu'on l'utilise pour un intranet ca ne gêne pas.Après pour avoir des certificats vraiment séparés il faut utiliser le mode tls ou le négociation se fait après la connexion sur le port 80. C'est possible, mais pas encore supporté par tous les navigateurs.