Lors de la migration d’un site vers le protocole HTTPS, plusieurs aspects doivent être pris en considération pour s’assurer que celui-ci continuera à fonctionner correctement chez tous les internautes qui le parcourront. Voici quelques conseils, qui sont des cas que nous avons rencontrés lors des migrations des sites de Poweb.info.

Note : Cet article est plutôt technique, mais il n’aborde l’aspect PHP que très épisodiquement, malgré la catégorie dans laquelle il a été publié. Il s’agit d’un retour d’expérience sur le passage de HTTP à HTTPS et nous ne ferons pas d’autres articles sur le blog à ce sujet.

 

Mais avant tout, quel est l’intérêt de HTTPS par rapport à HTTP ?

HTTPS est la combinaison du HTTP avec une couche de chiffrement TLS ; en d’autres termes, cela signifie que les informations transmises sont chiffrées avant d’être envoyées sur internet. Ce n’est donc pas le cas avec HTTP où les données sont envoyées en clair et peuvent donc être interceptées par des personnes non autorisées, rendant possible le vol de mot de passe et d’autres informations confidentielles.

De plus, certaines fonctionnalités puissantes liées à HTML5 comme l’API getUserMedia n’auront le comportement attendu que sur un site utilisant le protocole HTTPS – à l’heure où nous écrivons ces lignes, seul Google Chrome est concerné mais il est fort probable que les autres navigateurs suivent ce mouvement dans le futur.

Enfin, HTTP/2, la dernière révision majeure du protocole HTTP, ne supporte que les sites HTTPS ; ce n’est pourtant pas une exigence de la spécification, mais les principaux navigateurs du marché en ont décidé autrement.

Bref, tout semble indiquer que l’avenir du web est au HTTPS, et ce n’est pas le projet Let’s Encrypt / Certbot, fortement soutenu par de puissantes entreprises, qui devrait vous faire penser le contraire…

Vous avez un certificat déployé sur votre serveur ? Alors c’est parti, rentrons dans le vif du sujet avec les cas à considérer lors de la migration de son site vers le protocole HTTPS.

 

1 – Ne pas proposer du contenu mixte / mixed content

Vous devez vous assurer qu’une page servie via le protocole HTTPS ne va pas charger d’autres éléments qui seraient servis, eux, via le protocole HTTP. Ce problème peut facilement être constaté car il change l’aspect du cadenas vert – qui doit s’afficher ainsi sur toutes les pages HTTPS – à gauche de la barre d’adresses, sur tous les navigateurs.

Si du contenu mixte est chargé sur une page HTTPS, les conséquences sur l’affichage de la page ne seront pas les mêmes selon la nature du contenu :

– Le contenu mixte passif sera affiché correctement. Cela concerne les fichiers chargés depuis les balises <img>, <audio>, ou encore <video>.

– Le contenu mixte actif sera, lui, bloqué par le navigateur. Les fichiers appelés depuis les balises <script>, <link>, ou encore <iframe> ne seront donc pas chargés. Dans cette situation, il est probable que l’affichage de votre site soit « cassé » puisque les fichiers CSS et JavaScript n’auront pas été chargés.

Pour corriger les problèmes de contenu mixte, la solution est toute simple :  vous devez réécrire chaque lien concerné et remplacer http:// par https://. Toutefois, pour les fichiers hébergés sur des sites externes, vous devez vous assurer au préalable que ledit fichier est accessible lorsqu’il est appelé depuis le protocole HTTPS ; si ce n’est pas le cas, il n’y a malheureusement pas de solutions.

 

Quelques astuces pour régler ce problème rapidement…

Remplacer chaque lien http:// par https:// est facile mais la tâche peut être très longue si vous avez des centaines de liens – voire plus ! – à remplacer. Cependant, si ceux-ci sont stockés dans une base de données, vous pouvez exécuter une requête de ce type pour remplacer automatiquement tous les liens de votre site.
UPDATE maTable SET monChamp = REPLACE(monChamp, 'http://www.monsite', 'https://www.monsite')

Si vous préférez éviter de faire ce genre de manipulations avec la base de données, vous pouvez alors simplement modifier à la volée le contenu du texte avec PHP avant de l’afficher.
$texte = str_replace('http://www.monsite', 'https://www.monsite', $texte);

Enfin, vous pouvez ajouter un en-tête HTTP dans un fichier .htaccess pour demander au navigateur d’élever toutes les requêtes HTTP émanant de votre site en tant que HTTPS. C’est ce que fait Upgrade Insecure Requests ; attention toutefois, tous les navigateurs n’implémentent pas cette fonctionnalité de la même manière, cela ne vous dispense donc pas de réécrire tous les liens qui le nécessiteraient.
Header set Content-Security-Policy "upgrade-insecure-requests" env=HTTPS

 

2- Eviter le contenu en double / duplicate content

Une fois le problème du contenu mixte réglé, vous ferez certainement en sorte que les visiteurs qui accèdent à votre site via l’adresse http://www.monsite.com/ soit redirigé vers https://www.monsite.com/, ne serait-ce que pour éviter que votre site affiche le même contenu sur deux adresses différentes – http:// et https:// dans ce cas -, ce qui pourrait être assimilé par les moteurs de recherche à du contenu en double. Même si, d’après Google, « le contenu en double n’entraîne pas de conséquences négatives particulières pour votre site sauf si l’objectif semble être de tromper et de manipuler les résultats des moteurs de recherche » – et un site accessible aussi bien sur les protocoles HTTP que HTTPS n’a certainement pas vocation à « tromper » Google  – , montrez-vous tout de même prudent en ajoutant ce code dans le fichier .htaccess à la racine de votre site.
RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.monsite.com/$1 [QSA,L,R=301]

 

3- Tester le site pour éviter des « surprises » inattendues

Une fois que les deux étapes précédentes ont été réglées, votre site devrait fonctionner à merveille. Il faudra toutefois que vous testiez chaque page pour en avoir la certitude.

Mais il peut y avoir aussi des dysfonctionnements inattendus sur certains aspects. Certains le seront à cause d’une négligence de votre part ; d’autres en raison de la configuration du serveur.

Par négligence, on peut par exemple citer un formulaire envoyant des données en POST sur la version HTTP de votre site ; ce formulaire serait présent sur un site partenaire sur lequel vous n’avez aucun contrôle ou dans un logiciel dont vous ne disposez plus du code source. Problème : la redirection HTTP vers HTTPS mise en place plus tôt ne permet pas de conserver les données envoyées par le formulaire qui ne seront donc jamais reçues par votre script. La solution la plus simple et fiable est donc de faire une exception et de laisser la page concernée également accessible avec le protocole HTTP. Pour cela, il faut ajouter une règle dans votre fichier .htaccess.
RewriteCond %{REQUEST_URI} !^/?pageConcernee\.php

Enfin, si votre site est en ligne sur un hébergement mutualisé qui inclut des certificats Let’s Encrypt / Certbot – comme OVH –, il est possible que certains de vos scripts PHP, depuis que vous avez forcé l’utilisation du protocole HTTPS, retournent l’erreur suivante : SSL23_GET_SERVER_HELLO:unknown protocol. En fait, le diagnostic de ce problème est simple : toutes les fonctions qui font appel à un fichier en lien absolu sur le même site – ou les sites d’un même compte d’hébergement – échouent. La liste n’est pas exhaustive mais des fonctions comme file_get_contents(), fopen(), ou encore getimagesize() ne fonctionneront plus. Un responsable des hébergements web de chez OVH a expliqué les raisons de cette erreur : « elle provient du fait que, lorsque vous tentez d’appeler votre propre site sur le serveur web, il n’y a pas de certificat. En fait, lorsque vous faites une requête vers votre propre site, la requête ne repasse pas par nos load balancers mais passe seulement par les sockets internes du serveur web. Sauf que nous n’avons pas déployé les certificats sur les serveurs web : on n’aurait simplement pas la place de les stocker en local ». Avant d’énoncer une solution pour contourner ce souci : « Une possibilité est d’utiliser directement le port 443 en HTTP ». En voici un exemple :
$page = file_get_contents('http://www.monsite.com:443/pageConcernee.php');

 

Cette fois, c’est la bonne !

Voilà, la migration de votre site vers le protocole HTTPS devrait maintenant être terminée, avec le maximum de succès.

N’hésitez pas à nous faire des retours sur cet article dans la section des commentaires.