Migration d’un site web de HTTP vers HTTPS (SSL)

Logo

Introduction

Si il n’y avait jusqu’à maintenant aucune justification pour migrer un site Web du protocole HTPP vers le protocole sécurisé HTTPS avec SSL (Secure Socket Layer), ce n’est désormais plus le cas.

HTTP vs HTTPS

Pourquoi ? Au-delà de la justification d’établir des échanges réseaux sécurisés et encryptés pour se prémunir des attaques et "sniffeurs", 3 raisons motivent la migration vers HTTPS : l’indexation du site par Google, l’utilisation et les bénéfices du protocole HTTP 2 et enfin la crédibilité.

Pas à pas sont décrites ici les étapes réalisées pour migrer www.sqlpac.com vers le protocole HTTPS. L’hébergeur est ici OVH, le SSL est inclus dans l’abonnement et activé : les certificats sont délivrés par Let’s Encrypt, les renouvellements des certificats avant expiration (3 mois) sont également gérés par l’hébergeur OVH.

Un petit schéma pour comprendre comment fonctionne les certificats SSL avec Apache, un dessin vaut mieux qu’un très long laïus sur ce sujet complexe au premier abord pour un néophyte.

Mécaniqe SSL - Autorité de certification

La mécanique technique est plus détaillée dans l’article suivant : Apache 2.4. Virtual hosts sous Windows en HTTPS / SSL avec des certificats auto signés. Création et automatisation par macro.

Pourquoi migrer vers HTTPS ?

L’indexation Google et les statistiques Google Analytics

La raison principale de migrer vers le protocole HTTPS : l’indexation par les robots de Google (SEO - Search Engine Optimization). Même si un site web ne délivre que du contenu (pas de e-commerce, de sessions, etc.), Google et son moteur de recherche adoptent désormais la position du "HTTPS everywhere by default". Les algorithmes d’indexation de Google vont progressivement délaisser les pages servies avec le protocole non sécurisé HTTP.

Une autre raison très importante liée également à Google : les référents sont bloqués par Google Analytics dans les cinématiques HTTPSHTTP. Si une page utilisant le protocole HTTP est devenue virale dans des réseaux sociaux (reddit…), réseaux sociaux qui fonctionnent avec le protocole HTTPS, ces référents sont perdus dans les statistiques Google Analytics, ils ne sont historisés que lors d’une liaison HTTPSHTTPS. La perte de ces sources d’arrivée est plutôt fâcheuse pour l’analyse de son trafic.

Gains en performances avec HTTP 2

Google a développé SPDY (Speedy), un protocole expérimental HTTP pour améliorer les performances et les lacunes de la norme HTTP 1.1, norme qui date déjà de 1995. Depuis fin 2015 HTTP/2 est arrivé, protocole essentiellement basé sur SPDY, il est supporté par le serveur Apache à partir de la version 2.4.12 et par Nginx à partir de la version 1.9.5. La majorité des navigateurs supporte le protocole HTTP 2 depuis 2017.

HTTP 2 apporte des fonctionnalités majeures qui sont source de gains en performances :

  • Multiplexing et concurrence : les ressources sont chargées en parallèle via UNE seule connexion et non plus en séquentiel avec plusieurs connexions comme avec le protocole HTTP 1.1.
  • Dépendances de flux : le client peut indiquer au serveur les ressources prioritaires.
  • Compression des en-têtes (headers).
  • Push en avance de phase : le serveur HTTP peut être paramétré pour pousser des ressources (CSS, Javascripts…) avant que le client ne les demande.
multiplexing HTTP2
Multiplexing HTTP 2 vs HTTP 1.1 séquentiel

HTTPS / SSL est obligatoire pour exploiter le protocole HTTP 2.

La crédibilité

Et enfin, la dernière raison : la crédibilité.

Avec les paiements en ligne sur le web qui sont rentrés dans les mœurs, les internautes ont pour la plupart le réflexe de jeter un œuil sur la présence du cadenas garantissant le SSL et donc la sécurité dans la barre d’adresse. Et au delà du e-commerce, laisser simplement son email dans un formulaire sur un site HTTPS rassure l’internaute, d’autant plus que les navigateurs courants (Chrome, Firefox…) affichent explicitement le libellé "Non sécurisé" dans la barre d’adresse lorsque le protocole HTTP est utilisé.

site non sécurisé site sécurisé

Migration

Environnement de développement local

Pas question bien sur de migrer la production en direct, surtout si vous connaissez ou soupçonnez des codages en dur du protocole http:// dans des scripts Javascript, PHP… Il est tout à fait possible d’utiliser son environnement de développement local avec du HTTPS/SSL

L’article ci-dessous explique comment faire fonctionner un hôte virtuel avec Apache en local sous Windows avec du HTTPS/SSL et des certificats auto signés (self signed certificates).

Repérer et corriger tous les codages en dur http://

Avec votre éditeur préféré ou en lignes de commandes, repérer tous les codages en dur du mot clé http:// sur le site dans les scripts PHP (*.php, *.inc…), javascript (*.js), feuilles de styles css (*.css), etc.

find . -type f -print | xargs grep -i "http://"
        ...
./php/cls_gui.php:114: echo "<link rel=\"canonical\" href=\"http://"._WWW_HOST.parse_url($_SERVER['REQUEST_URI'],PHP_URL_PATH)."\">\n";
./php/cls_gui.php:170: echo "<base href=\"http://"._WWW_HOST."/"._APP_CODE."/\">\n";
...

Il est judicieux à présent de ne pas remplacer le codage en dur de http par un codage en dur de https, surtout si on souhaite qu’une portion du site continue à fonctionner en HTTP si HTTPS n’est plus opérationnel (expiration du certificat SSL…).

Pour les scripts PHP, selon l’agencement des classes mises en œuvre, créér une fonction globale publique appelée par exemple f_checkHttpsProtocol qui retourne TRUE ou FALSE si le protocole HTTPS est utilisé. Cette fonction envisage tous les cas de figure en fonction de l’environnement, cette information n’est en effet pas toujours retournée avec les mêmes variables globales d’environnement.

public function f_checkHttpsProtocol() {
        if ( ! empty($_SERVER['HTTPS']) && strtolower($_SERVER['HTTPS']) !== 'off')
        {
            return TRUE;
        }
        elseif (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && strtolower($_SERVER['HTTP_X_FORWARDED_PROTO']) === 'https')
        {
            return TRUE;
        }
        elseif ( ! empty($_SERVER['HTTP_FRONT_END_HTTPS']) && strtolower($_SERVER['HTTP_FRONT_END_HTTPS']) !== 'off')
        {
            return TRUE;
        }

        return FALSE;
}

En amont des scripts PHP, une constante _HTTP_PROTO est définie en fonction du code retour de la fonction f_checkHttpsProtocol() :

     $https_protocol = $this->f_checkHttpsProtocol();
     if ( $https_protocol ) { define("_HTTP_PROTO","https"); } else { define("_HTTP_PROTO","http"); }

Cette constante est exploitée pour ensuite éradiquer les codages en dur de http, on remplacera 

echo "<base href=\"http://"._WWW_HOST."/"._APP_CODE."/\">\n";

par :

echo "<base href=\""._HTTP_PROTO."://"._WWW_HOST."/"._APP_CODE."/\">\n";

Pour les codages en dur de http dans les scripts Javascripts, c’est plus simple, la propriété document.location.protocol est à disposition. Exemple :

var hostName = "http://" +  hostPrefixPages[1];

est remplacé par :

var hostName = document.location.protocol + "//" +  hostPrefixPages[1];

Pour les feuilles de style, en toute logique il ne devrait pas y avoir de codage en dur dans les directives @import, url('')… En principe, sauf exception, il ne devrait y avoir que les chemins absolus ou relatifs sans le protocole : 

@import url(style-print.css);
background-image: url('/images/user/background_adsense.png');

Les outils de développement des navigateurs et le "Mixed Content"

Les outils de développement des navigateurs, comme celui de Chrome (Ctrl Maj I) vont être d’une aide formidable pour détecter et corriger ce qu’on appelle le "Mixed Content", c’est-à-dire une page chargée en HTTPS/SSL mais avec des ressources qui ont dû être délivrées avec le protocole HTTP (images, feuilles de style, scripts Javascripts internes ou venant de tiers comme Google, AddThis…).

Se rendre dans l’onglet "Security", et toutes les informations sont à disposition : validité du certificat, contenu mixé (mixed content), formulaire non sécurisé - non-secure form (l’action pour le formulaire appelle le protocole HTTP et non HTTPS)…

Outils de développement - Mixed Content

À la fin de la migration, toutes corrections effectuées : tout doit être vert !

Outils de développement - Sécurité HTTPS / SSL OK

Opérations post migration

Redirection automatique de HTTP vers HTTPS avec Apache

Rediriger ensuite automatiquement les adresses en HTTP vers les adresses HTTPS correspondantes grâce au module de réécriture des URLs mod_rewrite d’Apache.

Dans le fichier .htaccess à la racine du site :

WWWROOT/.htaccess
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Cette procédure implique bien sûr que l’hébergeur autorise le module de réécriture, ce qui est généralement le cas.

Cette opération est à réaliser au préalable sur l’environnement local de développement pour vérifier qu’aucune régression n’apparaît en fonction de la complexité des règles de réécriture qui peuvent éventuellement déjà exister.

Liens canoniques

Même si la réécriture des URLs de http en https est en place, cela n’a aucun effet sur la définition des liens canoniques.

Donc, vérifier que les liens canoniques, très importants pour les robots Google et l’indexation, sont migrés eux aussi en HTTPS.

<link rel="canonical" href="https://www.sqlpac.com/referentiel/docs/apache-html-migration-http-https-ssl.html">

Bon nombre d’outils s’en chargent automatiquement (WordPress…), sinon vérifier ce point dans la boîte à outils PHP/Javascript utilisée.

Le fichier robots.txt

Penser à mettre à jour le fichier robots.txt pour refléter les adresses éventuelles avec https.

wwwroot/robots.txt
# robots.txt for https://www.sqlpac.com/
User-agent: *
Sitemap: https://www.sqlpac.com/referentiel/sitemap/sitemap-articles.xml
...

Google Search Console Site

Il faut ajouter le nouveau site https://www.sqlpac.com dans Google Search Console (anciennement Google Webmaster Tools) à partir du menu "Ajouter la propriété".

Google Search Console - Ajouter la prpriété Google Search Console - Ajouter https://www.sqlpac.com

Google vérifie que vous en êtes bien le propriétaire en demandant de déposer un petit fichier HTML à la racine du site, fichier à conserver même une fois la vérification effectuée.

Google Search Console - Procédure de validation Google Search Console - Validation réalisée

Resoumission des sitemaps en HTTPS

Générer les fichiers sitemaps nécessaires avec le protocole HTTPS dans les adresses.

https://www.sqlpac.com/referentiel/sitemap/sitemap-articles.xml
<?xml version="1.0" encoding="UTF-8"?>
 <urlset xmlns="http://www.google.com/schemas/sitemap/0.84" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.google.com/schemas/sitemap/0.84
                         http://www.google.com/schemas/sitemap/0.84/sitemap.xsd">
  ...
   <url>
     
     <loc>https://www.sqlpac.com/referentiel/docs/ravendb-3.4-installation-architecture-prise-en-main.html>/loc>
     <lastmod>2017-09-27>/lastmod>
     <changefreq>monthly>/changefreq>
     <priority>0.5>/priority>
   </url>
  ...
</urlset>

Envoyer ensuite les sitemaps dans Google Search Console Site pour le site en https. https://www.sqlpac.com Sitemaps

Google Search Console - Resoumission des sitemaps

Il faut attendre un petit peu avant de voir les statistiques arriver.

Google Analytics

Dans le profil Google Analytics : Administration Paramètres de la propriété, définir l’URL par défaut à https. Aucun historique n’est alors perdu et Google Analytics reprend à partir de la migration en HTTPS.

Google Analytics - https par défaut

Et les autres librairies tierces ? Google AdSense, Google Custom Search Engine, AddThis…

Pour Google Custom Search Engine, les moteurs de recherche personnalisé embarqués, depuis la version 2, le protocole https est déjà obligatoire (https://cse.google.com/cse.js…).

Pour Google AdSense (publicités) et AddThis (outil de partages), rien de particulier à paramétrer dans les consoles d’administration respectives, sauf si l’appel de ces librairies est encore effectué avec http. Il suffit de remplacer http par https et ça fonctionne comme avant.

http://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js
http://s7.addthis.com/js/300/addthis_widget.js https://s7.addthis.com/js/300/addthis_widget.js
http://q.addthis.com/feeds/1.0/trending.json https://q.addthis.com/feeds/1.0/trending.json

Dans leur grande majorité, soit les API tierces sont déjà en https, soit elles proposent à la fois le protocole http et le protocole https.

Conclusion

La migration est terminée, toutefois, surveiller pendant un laps de temps qu’il n’y a pas d’erreurs relevées dans :

  • Google Analytics.
  • Google Search Console (notamment les sitemaps).

Reste à vérifier si effectivement la migration en HTTPS fait remonter les statistiques des visites, ce qui pourrait très fortement laisser à penser que les robots Google commençaient déjà à délaisser le site en http.

Et maintenant que le site est HTTPS/SSL, il est temps de jouer avec les nouveautés du protocole HTTP 2, si l’hébergeur l’a implémenté, mais c’est une autre page qui s’ouvre.