J’ai fréquemment lu sur Internet qu’utiliser les hôtes virtuels, en partageant le même couple IP/port par Apache sur SSL était impossible.

La raison avancée est simple : les hôtes virtuels utilisent un champ de l’entête de la requête HTTP pour déterminer quel est le site concerné par la demande. Le problème qui gêne le bon fonctionnement des hôtes virtuels, est que cette entête est chiffrée puisque l’envoi des entêtes intervient après la présentation des certificats. Donc impossible d’identifier le site avant d’avoir envoyé les certificats, alors que cet envoi de certificats requiert d’avoir choisi le site. La boucle est bouclée, les débutants arrêtent de chercher sur les forums, et les achats d’IP supplémentaires augmentent chez les loueurs de serveurs dédiés.

C’était à moitié vrai, c’est complètement faux maintenant. C’est le problème d’Internet : on revient rarement en arrière corriger un vieux message sur les forums. Et les moteurs de recherche étant ce qu’ils sont, de vieilles pages plus du tout actuelles peuvent très bien remonter en haut des recherches.  Mais je diverge.

Donc malgré ce que vous pouvez lire, Apache est maintenant tout à fait capable de gérer les hotes virtuels en SSL.
Comment ? Au choix :
1- Apache (du moins en version 2.3 ou dans la branche 2.2 depuis 2.2.12 grâce à un backport) supporte les extensions SNI, qui permettent au navigateur de présenter le nom de domaine avant d’établir la connexion chiffrée. L’usage de cette extension requiert un navigateur compatible, ce qui inclut tous les navigateurs récents mais exclut le diabolique IE6 (encore et toujours lui). C’est une solution idéale si vous êtes prêts à passer outre ce vieux navigateur qui n’a que trop servi.
2- En utilisant le plus récent TLS, au lieu de SSL, avec le problème étendu de support par les navigateurs. Au passage, c’est la solution d’avenir, mais il vaut mieux l’oublier en attendant qu’il soit plus répandu.
3- Avec une solution plus vieille, qui a ses limitations, mais qui a fait ses preuves dans certains cas particuliers : un seul et même certificat pour tous les sites. On comprend vite qu’avec cette méthode, le problème énoncé en début d’article n’en est plus un. Alors que de base -pour une sécurité accrue- les certificats SSL sont signés à destination d’un seul et unique nom de domaine, il existe donc des variantes permettant les domaines multiples. Vous avez au choix les coûteux certificats wildcard ou l’utilisation de l’extenstion altName. Je vais encore réduire le spectre des solutions et choisir de parler ici du « altName », qui nous autorise à déterminer des noms alternatifs pour notre serveur. Je n’ai pas trouvé directement d’aides  sur Internet couvrant ce sujet du début à la fin avec des commandes simples qui se suffisent à elles-mêmes. D’où ceci :

Un rapide pas-à-pas détaillé

Placez vous dans un répertoire de travail (que je vous laisse créer). On commence par une génération de clés 1024 bits si vous n’en avez pas déjà une :

openssl genrsa -out server.key 1024

On copie ensuite le fichier de configuration d’openssl :

cp /etc/ssl/openssl.cnf .

On édite ce fichier. Dans la section [req] on ajoute (ou décommente) :

[req]
req_extensions = v3_req

Dans la section [v3_req], on ajoute alors la liste des domaines alternatifs sous cette forme :

subjectAltName= DNS:domaine1.org, DNS:autrealternative.domaine1.org, DNS:encoreunautre.com

Maintenant on génère une requête de signature. Si vous êtes riche, vous pouvez utiliser le fichier .csr ainsi généré pour faire certifier votre domaine auprès d’un organisme de confiance comme Thawte ou Verisign. Cela évitera les messages d’avertissement des navigateurs se connectant à votre site sécurisé. Voici la commande pour créer cette requête de signature :

openssl req -new -out server.csr -key server.key -config openssl.cnf

Au lieu d’envoyer votre demande chez les américains, si vous êtes près de vos sous et/ou dans un cadre amateur, ne vous gênez pas pour auto-signer votre certificat :

openssl x509 -req -in server.csr -out server.crt -signkey server.key -extfile openssl.cnf -extensions v3_req

Voilà, vous avez ainsi dans votre répertoire de travail deux fichiers (la clé et le certificat) qui sont suffisants pour faire tourner votre Apache en mode sécurisé !
N’oubliez pas d’activer mod_ssl dans Apache et d’ajouter dans votre configuration d’hôtes virtuels HTTPS les lignes suivantes :

SSLEngine on
SSLCertificateFile <chemin>/server.crt
SSLCertificateKeyFile <chemin>/server.key

Avant de partir, prenez connaissances des limitations de cette solution :  d’une part cette extension n’est pas reconnue par certains très vieux navigateurs (mais, puisque même l’horrible IE6 le fait, on va arrêter les chipotages et remettre au placard Netscape…), et d’autre part tous vos sites alternatifs sont présents dans le certificat en clair, ce qui veut dire que n’importe qui établissant la connexion SSL, peut savoir que ces sites existent sur votre machine.