Apache crée automatiquement une variable d'environnement interne nommée HTTPS et lui assigne la valeur on lorsque la ressource est demandée par l'intermédiaire du protocole sécurisé HTTPS. En HTTP normal, elle n'existera pas mais pour un comportement portable il est recommandé de tester à la fois sa présence puis sa valeur afin de pouvoir le déterminer précisément (sous IIS, elle sera définie mais de valeur off).

Vous pouvez donc regarder cette variable aussi bien dans un programme CGI que dans un script (PHP) ou encore lors d'une réécriture (voir Comment rendre certains documents accessibles uniquement par le protocole HTTPS ? pour des exemples).

Ne testez surtout pas les ports pour déterminer si vous êtes ou non en HTTPS : ce n'est en rien fiable contrairement à ce qui est dit ci-dessus ! On peut très bien configurer un serveur pour utiliser d'autres ports que les ports standards (bien que le client doivent les expliciter). Il est tout à fait possible de faire de l'HTTP sur le port 443 et de l'HTTPS sur le port 80.

Il est possible de réaliser la redirection de ressources particulières en vue de forcer, pour celles-ci, l'usage du protocole sécurisé (HTTPS). Pour ce faire, il est possible d'agir à plusieurs niveaux :

• Indiquer les redirections (directives Redirect*) directement depuis la déclaration du virtualhost HTTP correspondant (méthode à privilégier). Exemple :

   

  Sélectionnez

  <VirtualHost ...:80>
      # ...
      RedirectPermanent page_securisee.html https://www.monserveur.fr/page_securisee.html
  </VirtualHost>

• Depuis un fichier .htaccess et à l'aide du module de réécriture :

   

  Sélectionnez

  RewriteEngine On
  RewriteCond %{HTTPS} !=on
  RewriteRule secure[/_].* https://%{SERVER_NAME}%{REQUEST_URI} [R,L]

• Que l'on peut aussi, éventuellement, implémenter en PHP :

   

  Sélectionnez

  <?php
  if (!isset($_SERVER['HTTPS']) || $_SERVER['HTTPS'] != 'on') {
      header('Location: https://' . $_SERVER['SERVER_NAME'] . $_SERVER['REQUEST_URI']);
      exit;
  }

A l'origine, et jusqu'à peu en ce qui concerne le module standard ssl, il n'était pas possible, de par la conception même du protocole SSL, d'avoir plusieurs hôtes virtuels pour une même adresse IP. Pourquoi ? Il s'agit tout simplement du paradoxe de l'oeuf et de la poule : le protocole SSL encapsule HTTP et implique, au préalable, une négociation entre le client et le serveur sur la façon dont ils vont ensuite communiquer de manière sécurisée. L'entête HTTP déterminant le virtualhost (Host) ne peut donc être lue à ce moment, le serveur doit, avant cela, convenir des paramètres de connexion HTTPS selon sa propre configuration et fournir son certificat. C'est ensuite, donc trop tard, que l'entête Host est lue. Apache n'a donc d'autre choix, dans un tel cas de figure, que de s'en remettre à un virtualhost par défaut (le premier de la liste).

Voici une caricature de la négociation :

_ client : (négociation TLS) Salut, je supporte telle et telle méthodes de chiffrement.
_ serveur : (négociation TLS) Bonjour, voici mon certificat public, nous allons utiliser tel algorithme de chiffrement.
_ client : (négociation TLS) ça me semble bon.
_ client : (chiffré) requête HTTP
_ serveur : (chiffré) réponse HTTP

Aujourd'hui, les versions récentes d'Apache (>= 2.2.12) et OpenSSL (>= 0.9.8j) (à moins d'avoir été patchés et/ou compilés à la main) implémente une solution qu'est l'extension appelée Server Name Indication (d'acronyme SNI, RFC 4366) du protocole SSL. Elle permet alors au client d'indiquer dès le départ, lors de la négociation SSL, le nom de domaine désiré. Le serveur est alors capable d'associer à la requête le bon hôte virtuel.

Illustration des échanges client/serveur avec SNI :

_ client : (négociation TLS) Salut, je supporte telle et telle méthodes de chiffrement, et je cherche à me connecter à 'www.exemple.fr'.
_ serveur : (négociation TLS) Bonjour, voici mon certificat public, nous allons utiliser tel algorithme de chiffrement.
_ client : (négociation TLS) ça me semble bon.
_ client : (chiffré) requête HTTP
_ serveur : (chiffré) réponse HTTP

Mais encore faut-il que le client supporte cette extension. A défaut, soit il sera dirigé sur le virtualhost par défaut (lorsque SSLStrictSNIVHostCheck est à off - comportement par défaut) soit il verra sa requête refusée (erreur 403 avec un message d'erreur indiquant son incapacité à prendre en charge SNI) lorsque SSLStrictSNIVHostCheck est à on.

Si vous disposez déjà d'un hôte virtuel en HTTPS, vous pouvez contrôler le support de SNI via cet espace. En effet, le module SSL créera automatiquement, s'il est actif, une variable d'environnement interne à Apache appelée SSL_TLS_SNI, prenant pour valeur le nom de votre virtual host.

Comme pour la variable HTTPS, vue plus haut, vous indiquant ou non si la ressource a été appelée par le protocole sécurisé, il vous sera facile de l'exploiter via le module de réécriture, un programme CGI, en PHP, etc.

Un code PHP pour effectuer cette vérification :

<?php
if (isset($_SERVER['HTTPS']) && strtolower($_SERVER['HTTPS']) == 'on') {
    if (isset($_SERVER['SSL_TLS_SNI']) /*&& $_SERVER['SSL_TLS_SNI'] == $_SERVER['HTTP_HOST']*/) {
        echo "SNI est supporté par ce serveur";
    } else {
        echo "SNI n'est pas supporté sur ce serveur";
    }
} else {
    die("Ce script doit être exécuté en HTTPS.");
}