Hôtes virtuels HTTPS et certificats « wildcard » avec Apache

« Par définition », il n'est pas possible de définir plusieurs hôtes virtuels (vhosts) partageant une même adresse IP et un même port (dit name-based vhosts). En effet, le certificat X509 contient traditionnellement le nom FQDN du serveur ; lors de la connexion SSL/TLS d'un client au serveur, ce dernier doit choisir le bon certificat à présenter au client et ce avant que le client n'envoie sa requête HTTP… requête contenant le nom du serveur.

Une première solution existe : enregistrer plusieurs noms FQDN dans un même certificat X509 (avec des subject Alt Names de type dNSName), cf. la RFC 2818 comme par exemple expliqué là.

Une seconde solution est possible dans un même domaine (ou sous-domaine) en utilisant un certificat wildcard. Ce certificat a pour objet (common name aka CN) *.domain.tld (ou *.subdomain.domain.tld…) comme expliqué dans la même RFC 2818. Dès lors, on peut avoir plusieurs vhosts sur HTTPS partageant une même adresse IP pourvu que ces vhosts soient dans le même (sous-)domaine DNS.

La configuration du daemon Apache (2.2 ici) nécessite alors les directives « classiques » pour des vhosts HTTP comme par exemple pour un certificat *.example.com :

Listen 192.0.2.80:443
NameVirtualHost 192.0.2.80:443
 
<VirtualHost 192.0.2.80:443>
   ServerName alpha.example.com
   SSLCertificateFile    /path/to/wildcard.crt
   SSLCertificateKeyFile /path/to/wildcard.key
   ...
</VirtualHost>
<VirtualHost 192.0.2.80:443>
   ServerName beta.example.com
   SSLCertificateFile    /path/to/wildcard.crt
   SSLCertificateKeyFile /path/to/wildcard.key
   ...
</VirtualHost>

Le certificat et la clef sont identiques pour les deux vhosts, le reste est trivial. Pour s'assurer que tous les clients, y compris les vieilles versions, pourront se connecter comme souhaité, il faut ajouter la directive globale :

SSLStrictSNIVHostCheck off

Cela ne fonctionnera qu'avec le support de Server Name Indication, disponible depuis les versions 0.9.8j d'OpenSSL, 0.20 de GnuTLS et 2.2.12 d'Apache. Cette dernière extension du protocole TLS permet justement de dépasser la limite expliquée au début. De plus, cette dernière extension requiert l'abandon de SSLv2 au profit de SSLv3 ou TLSv1 ; il convient donc de limiter l'usage de SSLv2 : dans la directive SSLCipherSuite, enlever SSLv2 :

SSLCipherSuite ALL:-SSLv2:!EXPORT56:!ADH::+HIGH:+MEDIUM