Et la marmotte ...

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.

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 :

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

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)