Parfois, on apprend des choses en lisant les docs, notamment la section qui indique les nouveautés de la dernière version d’un logiciel.
En lisant celles d’Apache 2.2, je tombe ainsi sur l’extrait suivant :
Autrement dit, il serait possible de se débarrasser des ennuyeux https:// (sites sécurisés par SSL), en mettant tout en http:// et en laissant le serveur et le navigateur se débrouiller pour négocier tout ce qu’il faut, comme cela se fait déjà pour la plupart des autres protocoles (SMTP, LDAP, POP, IMAP…). Avantage supplémentaire, plus besoin d’avoir une adresse IP distincte pour chaque site https, une des grosses contraintes de SSL tel qu’il est utilisé actuellement. Un vieux rêve de webmaster.
Sauf que. En allant lire la documentation du module concerné, on est vite refroidi :
In Apache 2.1 and later,
SSLEnginecan be set tooptional. This enables support for RFC 2817, Upgrading to TLS Within HTTP/1.1. At this time no web browsers support RFC 2817.
La RFC en question date de 2000. Il a donc fallu environ 7 ans pour que ce soit mis en oeuvre dans le serveur web le plus populaire. Reste à espérer qu’il ne faudra pas 7 ans de plus pour que ce soit intégré dans les navigateurs !
Il semblerait que ce soit prévu pour la version 3 de Firefox 🙂
Alors, tu dis, “Avantage supplémentaire, plus besoin d’avoir une adresse IP distincte pour chaque site https, une des grosses contraintes de SSL tel qu’il est utilisé actuellement.”.
Or, ça fait longtemps que c’est possible, regarde le certificat dispo sur https://mat.cc/, comme expliqué sur http://wiki.cacert.org/wiki/VhostsApache 🙂
mat : j’ai vu ton exemple cité quelque part (dans la doc apache peut-être), c’est un cas particulier, tu as un seul certificat pour tous les sites. Ce n’est pas utilisable pour héberger des sites vraiment distincts avec certificats séparés. Un autre cas particulier similaire est le certificat “wildcard” qui peut être utile lorsque tous les sites font partie d’un même domaine.