Les certificats SSL/TLS (X.509) se généralisant et les IPs publiques étant coûteuses, on peut chercher à servir plusieurs noms de domaine avec une seule IP.
Pour résoudre ce problème, l’extension SNI a été ajoutée au protocole TLS, ainsi qu’au protocole SSL à partir de la v3 (RFC 4366).

SNI : Server Name Indication

Définition (Wikipedia)

Server Name Indication (SNI), qui peut se traduire par « indication du nom du serveur », est une extension du protocole TLS. Avec l’extension SNI, le client indique le nom d’hôte (hostname) avec lequel il tente de démarrer une négociation TLS. Cela permet au serveur de présenter plusieurs certificats pour la même adresse IP (mais des noms d’hôte différents), et donc de mutualiser des hébergements pour des sites sécurisés en https.

Tous les navigateurs web ne supportent pas le SNI. Lorsque le navigateur ne supporte pas le SNI, le serveur fournit le certificat par défaut, et un avertissement au sujet du certificat se produit donc le plus souvent.

Exemple concret

Imaginons que nous disposions d’un tenant Openstack avec un nombre limité d’adresses IP publiques.
Plusieurs solutions s’offrent à nous :

• les sites ont tous un nom qui se termine par le même domaine (*.domaine.fr)
  => Dans ce cas, on peut utiliser un certificat Wildcard ou OmniDomaine
• les sites ont des noms divers et on a une seule adresse IP
  => Dans ce cas, on peut utiliser un certificats Multiples Sites (SSL SAN)
  => Pour ça, il faut connaitre l’ensemble des noms de domaine à la création du certificat qui sera partagé
• les sites ont des noms divers, on a une seule adresse IP et on met en place le SNI
  => Dans ce cas, chaque domaine pourra avoir son propre certificat
  => Il faut vérifier la problématique d’incompatibilité, mais elle est de plus en plus faible avec le temps

Problématique

Pour que le SNI fonctionne, il faut d’abord avoir un serveur compatible (par exemple Apache pour un serveur web, HAProxy pour un load balancer), le mettre en place et le configurer bien sur, mais aussi avoir des clients (navigateurs) compatibles.
Côté serveur, au pire une montée de version règle le problème.
Côté client, on exclue les plus vieux navigateurs et/ou les plus vieux systèmes d’exploitations.

Compatibilité

• Navigateurs compatibles:
  • Internet Explorer 7+ ou plus récent, sur Windows Vista ou plus récent. Ne fonctionne pas sur Windows XP et Internet Explorer 8
  • Mozilla Firefox 2+
  • Opera 8+ (le protocole TLS 1.1 doit être mis en place)
  • Opera Mobile, la version doit être au moins 10.1 beta sur Android
  • Google Chrome (Windows Vista ou plus récent, Windows XP nécessite Chrome 6+, OS X 10.5.7 ou + nécessite Chrome 5.0.342.1 ou +)
  • Konqueror/KDE 4.7+
  • Safari 3.2.1+ sur Mac OS X 10.5.6+
  • Safari sous Vista ou Seven
  • MobileSafari sur iOS 4.0+
  • WindowsvMobile 7+
  • BlackBerry OS 7.2+
  • Android (navigateur standard) 3+ pour tablette et 4+ pour smartphone
  • MicroB sur Maemo
  • wget 1.14+
  • curl 7.18.1+
• Serveurs compatibles:
  • Microsoft IIS8
  • OpenSSL 0.9.8f (0.9.8k recommandé)
  • Apache 2.2.12+ (doit utiliser le mod_ssl)
  • Apache Traffic Server 3.2.0+
  • Cherokee  (avec support TLS implémenté)
  • lighthttpd 1.4.24+
  • Apache Tomcat sur Java 7+
  • Nginx (avec OpenSSL et support SNI)
  • F5 Networks Local Traffic Manager 11.1+
  • G-WAN Web app. Server (avec OpenSSL et support SNI
  • LiteSpeed 4.1+
  • Pound 2.6+
  • Saetta Web Server via OpenSSL
  • Citrix NetScaler 9.2+
  • HAProxy 1.5+
  • Qt 4.8+
  • Java 7+
  • Python 2.7.9+ pour les 2.x et 3.2+ pour les 3.x (dans les modules ssl, urllib et httplib)