Migrer son site de HTTP vers HTTPs
Quid de HTTP ou de HTTPS ?
Lorsqu’un navigateur envoie une requête vers le serveur, il existe alors deux types de protocoles possibles, le HTTP qui emploie le port 80, et l’HTTPS qui lui emploie le port 443.
La barre URL du navigateur nous informe constamment sur la nature de cette communication. La présence d’un petit cadenas ouvert situé à gauche de l’URL indique l’emploie du protocole HTTP. Si HTTPS est employé, alors le cadenas est verrouillé. En cliquant sur le cadenas, il est également possible d’obtenir toute une série d’informations sur la nature de la connexion en cours.
Quoiqu’il en soit, et dans les deux cas, les pages renvoyées par le serveur sont chargées et affichées sans aucune différence visible par l’internaute. La réelle différence vient que les échanges réalisés sont chiffrés et certifiés, ou pas.
Pour assurer les communications entre le client et le serveur HTTPS s’appuie sur le protocole TLS, d’où le S qui signifie Secure. En tant que développeur, il est important de vérifier auprès du serveur d’hébergement vers où chacun de ces protocoles pointe. Parfois, les deux se partage le même dossier racine, mais il est possible que chacun puisse avoir son propre dossier racine, par exemple httpdocs et httpsdocs. Ceci aura son importance lors de la bascule de HTTP vers HTTPS.
TLS ou SSL ?
On parle toujours de SSL, mais en réalité SSL est obsolète depuis plusieurs années. Historiquement, dès la mise en place de HTTP on s’est aperçu de larges failles de sécurité lors des transferts et rapidement HTTP s’est alors appuyé sur le protocole SSL (Secure Socket Layer). Cependant de nouvelles failles sont apparues, et malgré le renforcement de SSL avec SSL 2 .0 puis SSL 3.0, de nouvelles failles ne cessaient d’être découvertes.
Un nouveau protocole a donc été mis en place, TLS (Transport Layer Security). Il correspond un peu à l’évolution de SSL 3.0 et aujourd’hui, bien que la version la plus utilisée soit TLS 1.2, il est également disponible sous la version TLS 1.3.
Quoiqu’il en soit, on continue à évoquer le terme de SSL pour définir la sécurisation des transferts.
Compagnon du protocole sécurisé, le certificat.
Tout commence par le dépôt d’un certificat sur le serveur. Ce certificat obtenu auprès d’une autorité, permet d’une part d’identifier le client ainsi que le serveur en garantissant que la requête envoyée par le client arrive bien sur le serveur invoqué, et que d’autre part les échanges aussi bien montants, que descendants, soient chiffrés et ne puissent donc ni provenir d’un tiers, ni être déchiffré.
Ces certificats sont disponibles auprès de fournisseurs comme SSL2buy (principalement orienté Comodo), GlobalSign, Digicert, et bien d’autres, il suffit de googler sur le sujet pour en découvrir d’autres. On remarque vite que les tarifs peuvent s’échelonner d’une dizaine d’euros, jusqu’à plusieurs centaines d’euros sur des abonnements annuels.
Lequel choisir ?
Eh bien, tout va dépendre de la sensibilité de votre site et des garanties dont vous, et vos clients, avez besoin de vous entourer. Cependant, il existe une solution open source, gratuite, qui mérite attention, et qui commence à devenir utilisé par un grand nombre de sites web, Let’s Encrypt.
Il suffit de se rapprocher de certaines sources de statistiques pour vérifier la popularité et l’usage de tous les certificats en vogue. Il est toujours bien de croiser les sources, prenons par exemple appui sur w3techs, ou encore Censys.
Vérifiez également auprès de votre hébergeur, et surtout depuis l’interface d’administration de votre serveur afin de vous assurer si l’utilisation de certificat gratuits n’y est pas directement accessible. Vous pouvez quoiqu’il en soit, toujours opter pour une solution externe si vous le souhaitez. Attention, les certificats ont une durée de validité maximale qui a été fixée à 13 mois, et il faut donc penser à les renouveler le moment venu. Généralement cette tâche est directement prise en charge par les consoles d’administration de nos serveurs, mais quand bien même, un mail d’alerte sera envoyé pour prévenir l’administrateur ayant requis le certificat.
Comment fonctionne cet échange sécurisé ?
Lors du premier envoi d’une requête vers le serveur, le client sollicite la mise en place d’une connexion sécurisée. C’est à ce niveau, qu’en fonction de la version du navigateur utilisé, que la prise en charge ou non du, ou des, protocoles disponibles sur le serveur, peut causer soucis.
C’est pour cela que TLS 1.2 est largement répandu, car bien que 1.3 soit depuis longtemps disponible certains clients peuvent ne pas le gérer.
Vous pouvez également vérifier les protocoles disponibles sur le domaine sollicité au travers du site de SSLlabs, en saisissant l’URL visée.
Une fois la requête envoyée, le serveur renvoie donc son certificat afin que le client puisse vérifier qu’il s’agit bien du domaine sollicité. N’oublions pas que le certificat est généré par une autorité qui garantit l’identité et la véracité d’affiliation au nom de domaine de son détenteur.
La clé publique contenu dans le certificat permet à son tour au client, non seulement de s’identifier mais aussi d’établir une connexion chiffrée qui sera employé durant toute la session.
Cette clé permet donc au client aussi bien de déchiffrer les informations reçues, que de chiffrer les informations qu’il renvoie. Le serveur lui de son côté possède une seconde clé, privée cette fois ci, qui permet de pouvoir s’assurer que les échanges correspondent bien à ceux appartenant à la connexion initialement établie et encodés par la clé publique.
Comment basculer en HTTPS ?
Une fois le certificat déposé, il faut alors s’assurer que chacune des pages du site ne fassent pas appel à des ressources en HTTP. Tout fichiers dépendants, qu’il s’agisse de CSS, JavaScript, Images, CDN, Fontes, Icônes, etc… doit donc être impérativement invoqués en HTTPS.
Suivant la nature du site, cette tâche qui au départ s’apparente à une simple opération de rechercher http:// à remplacer par https:// (hors hyperliens) peut vite devenir complexe et chronophage, surtout s’il s’agit d’un CMS de type WordPress.
À cet effet il existe le plugin Velvet Blues Update URLs qui peut s’avérer être de grande utilité. Malgré cela, il vous faudra également vous rendre dans votre back office, onglet Réglages > Général et modifier les deux URLs Adresse web de WordPress (URL) et Adresse web du site (URL) en vous assurant que les deux utilisent bien le protocole HTTPS.
Notez que certains plugins peuvent causer soucis, notamment les extensions qui font appels à des éléments externes, comme les carrousels images, ou les sliders. Il vous faudra parfois intervenir directement dans la base de données. Dans certains cas des plus récalcitrants, le plus simple reste encore d’exporter la base de données au format SQL, de l’ouvrir dans NotePad++, et de réaliser un rechercher / remplacer avant de réimporter la base. Attention cependant, du fait de l’échappement de certains caractères, il faudra parfois rechercher http:\/\/ au lieu http://. Un back slash permettant d’échapper le slash présent dans l’URL.
Quoiqu’il en soit, si vous devez intervenir sur votre base de données, que celle-ci soit associée à WordPress, ou pas, n’oubliez surtout pas d’en faire une sauvegarde avant toute intervention.
Forcer le passage en HTTPs
Bien qu’un certificat ait été déposé, et bien que la bascule des fichiers dépendants vers HTTPS ait été réalisée, le site peut toujours rester accessible via le protocole HTTP. Quelque part cela n’est pas plus mal, cela va vous permettre de vérifier qu’il n’y ait pas de pages d’avertissement ici ou là, ou que certaines pages ne soient pas bloquées car toujours invoquées en HTTP.
Le plus simple pour s’en assurer reste de naviguer sur le site, en HTTPS et en ayant pris soin d’ouvrir la console afin de vérifier si des ressources ne restent pas bloquer par le navigateur. Pour vous en rendre compte, cliquez sur cette page de test, ouvrez la console de votre navigateur, si rien ne se passe rechargez la page une fois la console ouverte. Vous devriez constater que la feuille de style CSS n’a pas été prise en compte par le navigateur.
Une fois que le site est vérifié, il faut maintenant penser à se séparer de l’accès par protocole HTTP car d’une part cela pourrait induire en erreur les visiteurs, mais surtout et d’autre part, cela va créer un Duplicate Content.
Bien qu’en réalité il s’agisse du même site, étant accessible par deux ports distincts (80 et 443) il est considéré comme deux sites distincts par les moteurs de recherche.
Pour éviter cette problématique, et surtout si l’hébergement se scinde en deux dossiers respectifs un pour HTTP et un pour HTTPS, il est intéressant d’utiliser une balise <link> pointant l’adresse canonique du site, à savoir celle accessible par le protocole HTTPS.
<link rel="canonical" href="https://www.puce-et-media.com/" />
Cela aidera les moteurs de recherche à mieux prendre en charge la migration. À ce sujet la vidéo de Matt Cutts, Canonical Link Element, est vraiment intéressante et permet de mieux comprendre les URLs au sens large.
Il est également possible d’intervenir sur le fichier robots.txt. Un premier demandant aux moteurs de recherche de ne pas indexer le contenu et en laissant le soin à un second de le faire. Une fois encore si l’hébergement HTTP et HTTPS se trouve dans deux dossiers distincts, il suffit de déposer le fichier robots.txt Adhoc dans chacun des dossiers.
Par contre si l’hébergement est centralisé sur un seul et unique dossier, il faut alors créer deux fichiers robots distincts par exemple robots.txt et robotshttps.txt et s’appuyer sur un .htaccess qui reniflerait le port utilisé afin d’orienter le crawler vers le fichier robots adéquat.
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{SERVER_PORT} ^443$
RewriteRule ^robots\.txt$ robotshttps.txt [L]
</IfModule>
Bien que ces deux approches puissent satisfaire les moteurs de recherche, les utilisateurs eux peuvent, le cas échéant, toujours pointer vers le site ayant le cadenas ouvert, et n’auront aucune garantie de sécurité, surtout si des données sensibles doivent y être échangées.
Donc il faut avoir recours à une méthode plus ferme réorientant toutes requêtes HTTP, vers du HTTPS, et pour cela il est préférable de directement employer un fichier .htaccess de redirection.
Comme nous l’avons évoqué lors de l’introduction, certains hébergements font pointer les deux protocoles HTTP et HTTPS vers deux dossiers distincts, donc si cela est le cas, il faut placer un fichier .htaccess dans le premier afin de rediriger les requêtes vers le second.
Redirect permanent / https://www.puce-et-media.com/
Il reste également à prendre en compte les requêtes qui seraient toujours formulées vers du HTTP. Pour cela, il faut alors ajouter un fichier .htaccess dans le dossier HTTPS en demandant au serveur de réécrire les requêtes HTTP en HTTPS. Par la même, et afin d’éviter un Duplicate Content entre https://www.puce-et-media.com et http://puce-et-media.com il est intéressant de réécrire les requêtes vers une unique entrée :
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteCond %{HTTP_HOST} ^(?:www\.)?(.+)$ [NC]
RewriteRule ^.*$ https://www.%1%{REQUEST_URI} [L,NE,R=301]
</IfModule>
Ceci devrait prendre en charge les requêtes envoyées par le client mais aucunement les liens internes réclamant des fichiers dépendants. Donc il ne faut surtout pas omettre l’étape précédente, où il fallait modifier l’ensemble des liens concernant les fichiers dépendants.
Conclusion
Dorénavant le site devrait être basculé et accessible en HTTPS.
