Passer un site WordPress ancien en HTTPS

Cela faisait longtemps que j’avais repéré la manière de passer un site existant de http à https. Contrairement à un site neuf, il y a un certain nombre de manipulations à réaliser pour éradiquer les http résiduels, notamment dans la base de données (mixed contents et duplications). Et ça peut se révéler très chronophage, surtout quand le CMS tourne depuis dix ans, comme c’est le cas du site où vous vous trouvez, infodocbib.net, ouvert en 2010.

Le confinement m’a donné l’occasion de faire le nécessaire pour obtenir le fameux petit cadenas vert :

Le https fera plus sérieux sur mon portfolio comme sur mon CV… Mais pas que :

• Quel est l’intérêt d’avoir un site web en HTTPS ?

Avant de commencer, ayez en tête ceci : les compteurs de vos boutons de partage seront irrémédiablement perdus, sauf à utiliser L’extension premium Social Warfare. Vous pensez que le certificat HTTPS est plus important? Alors allons-y ! 😉

Sommaire :

• 1. Se procurer un certificat SSL
• 2. Les choses à faire absolument après l’activation du HTTPS
  • 2.1. Tout rediriger vers le site en HTTPS
  • 2.2. Remplacer les URL en HTTP
  • 2.3. Vérifier les ressources chargées par le thème : les mixed content
  • 2.4. Forcer le HTTPS dans l’administration
  • 2.5. Mettre à jour le fichier robots.txt
  • 2.6. Tester votre certificat SSL/TLS
• 3. Mettre à jour la nouvelle adresse de votre site partout où c’est possible
• 4. Ce qui me resterait à régler : la version obsolète de TLS

1. Se procurer un certificat SSL

C’est le plus facile. Il suffit de se laisser guider par l’interface de notre hébergeur. OVH fourni même un tuto pour commander puis activer un certificat SSL.

Web > Hébergement > [Votre site] > Informations générales > Configuration : c’est juste en dessous du choix de la version de PHP.

J’ai opté pour la version gratuite Let’s Encrypt, fourni par la plupart des hébergeurs. Une fois le certificat obtenu, il faut l’activer dans l’onglet « Multisite ». Tout est très bien expliqué dans la documentation d’OVH :

• https://docs.ovh.com/fr/hosting/les-certificats-ssl-sur-les-hebergements-web/
• Comment Let’s Encrypt a changé la face du web – ZDNet

↑ — Revenir au sommaire

2. Les choses à faire absolument après l’activation du HTTPS

Une fois que le certificat est actif sur votre nom de domaine, c’est là que les choses se corsent. Avec un site neuf, on entre directement https partout où c’est nécessaire pendant sa création et le tour est joué. Avec un site pré-existant qui a fonctionné parfois des années en http, il faut mettre à jour toute une série d’éléments. Pour ne rien oublier, je me suis appuyé sur l’article de WPMarmite consacré au sujet, que je gardais sous le coude depuis sa publication. J’ai suivi la doc OVH en parallèle :

• https://wpmarmite.com/wordpress-https/
• https://docs.ovh.com/fr/hosting/passer-site-internet-https-ssl/

Attention, toutes les extensions ne sont pas bonnes à installer :

• Really Simple SSL n’est pas votre ami !

↑ — Revenir au sommaire

2.1. Tout rediriger vers le site en HTTPS

Si on pourra ensuite tout changer sur le site lui-même, on n’aura jamais la main sur tous les accès extérieurs qui pointent vers nous. Il faut donc mettre en place une redirection 301. Sans quoi, Les moteurs de recherche, Google en tête vont croire à du contenu dupliqué, accessible à la fois en http et en https. Et Google a horreur du contenu dupliqué. Pour cela, il suffit d’ajouter le script suivant au début de votre fichier .htaccess , qui se trouve à la racine de votre site :

# Redirection vers HTTPS
RewriteCond %{SERVER_PORT} ^80$ [OR]
RewriteCond %{HTTPS} =off
RewriteRule ^(.*)$ https://monsite.com/$1 [R=301,L]

# Redirection du www vers non-www00a31a en HTTPS
RewriteCond %{HTTP_HOST} ^www\.monsite\.com [NC]
RewriteRule ^(.*)$ https://monsite.com/$1 [R=301,L]

Il existe des variantes selon que vous utilisiez le www ou pas.

• En savoir plus sur les redirections : https://wpmarmite.com/htaccess-wordpress/#creer-redirections
• Les problèmes de contenus dupliqués : https://wpmarmite.com/pat-episode-021/

Il est ensuite fortement recommandé d’utiliser un outils de vérification pour vous assurer que les redirections se font correctement. Par exempe Why No Padlock?

↑ — Revenir au sommaire

2.2. Remplacer les URL en HTTP

C’est maintenant le moment de mettre à jour toutes les URL en HTTP de votre site vers HTTPS. WordPress étant un CMS qui génère ses pages à partir d’une base de données, c’est dans celle-ci que vous allez opérer. Alex de WPMarmite fournit un script pour ce faire.

Pour ma part, j’ai opté pour des requêtes SQL dans le phpmyadmin associé à mon site (https://phpmyadmin.ovh.net/).

Entrez vos identifiants, sélectionnez votre base de données et allez dans l’onglet SQL

Ces requêtes sont les mêmes que celles qu’on utilise quand on transfère un site en local vers un serveur chez l’hébergeur (et vice-versa pour les sauvegardes).

# Changer l'URL du site
UPDATE wp_options
SET option_value = REPLACE(option_value, 'ancienneUrlSite', 'nouvelleUrlSite')
WHERE option_name = 'home'
OR option_name = 'siteurl';

# Changer l'URL des GUID
UPDATE wp_posts
SET guid = REPLACE (guid, 'ancienneUrlSite', 'nouvelleUrlSite');

# Changer l'URL des médias dans les articles et pages
UPDATE wp_posts
SET post_content = REPLACE (post_content, 'ancienneUrlSite', 'nouvelleUrlSite');

# Changer l'URL des données meta
UPDATE wp_postmeta
SET meta_value = REPLACE (meta_value, 'ancienneUrlSite', 'nouvelleUrlSite');

Outre les « votresite.com« , ne faites pas comme moi et n’oubliez pas de transposer aussi les en-têtes de tables, qui ne sont pas nécessairement en « wp- » (il même recommandé qu’ils ne le soient pas, c’est une question de sécurité)

↑ — Revenir au sommaire

2.3. Vérifier les ressources chargées par le thème : les mixed content

Parfois, il arrive que le thème charge toujours des fichiers (CSS, JS ou autre) en HTTP au lieu de HTTPS. On appelle ça les contenus mixtes (mixed content). À qui la faute ? À l’auteur du thème (ou la vôtre si vous avez bricolé votre thème enfant n’importe comment). Là pas de mystère, si c’est votre cas, il faudra mettre les mains dans le code de vos fichiers de thème, en vous aidant de l’inspecteur de code de votre navigateur, onglet Console.

WPMarmite propose de contourner le problème avec une extension : SSL Insecure Content Fixer.

Quand à moi, mon thème était correctement écrit et Why No Padlock?, cité plus haut, m’avait déjà dit que je n’avais aucun mixed content :

Cependant, j’avais toujours des erreurs dans le navigateur : il me trouvait encore des occurrences en http, alors que j’étais sûr d’avoir tout remplacé. J’ai fini par comprendre que ces occurrences venaient du cache de mon site. Avoir un cache de son site est très bon pour le SEO (il existe un grand choix d’extensions qui font cela très bien), mais on a tendance à l’oublier une fois paramétré. Je suis donc allé purger le cache généré par WordPress, et le cadenas tant attendu est enfin apparu.

↑ — Revenir au sommaire

2.4. Forcer le HTTPS dans l’administration

Code dans le fichier wp-config.php : inutile pour mon cas, la manip du début dans .htaccess s’étant révélée suffisante.

2.5. Mettre à jour le fichier robots.txt

Ajouter un « s » à l’adresse du sitemap de votre site.

2.6. Tester votre certificat SSL/TLS

J’y reviendrai plus tard. Entrez votre nom de domaine ici et attendez le résultat : https://www.ssllabs.com/ssltest/

↑ — Revenir au sommaire

3. Mettre à jour la nouvelle adresse de votre site partout où c’est possible

Votre site est comme un nouveau site avec son protocole HTTPS. Il faut donc le faire savoir à tous vos outils de mesure (Xiti, Statcounter, Matomo, etc, selon votre choix), ainsi que partout où le nom de votre site apparaît.

↑ — Revenir au sommaire

4. Ce qui me resterait à régler : la version obsolète de TLS

J’ai eu une mauvaise surprise quand j’ai testé mon SSL sur https://www.ssllabs.com/ssltest/ (point 2.6 ci-dessus)

A vrai dire, le problème apparaissait déjà dans Why No Padlock? (points 2.1 et 2.3 ci-dessus)

Comme on vient de le voir, cela n’empêche absolument mon site de fonctionner et même de très bien fonctionner selon Google PageSpeed Insights. Les choses seraient différentes s’il s’agissait d’un site marchand. Les versions TLS 1.0 et 1.1 sont en effet considérées comme obsolètes. Il faut une version 1.2 ou 1.3 pour pouvoir faire tourner une solution de paiement comme Paypal.

Je comprends mieux le message que m’envoie Filezilla depuis 2018, chaque fois que je veux faire du FTP sur mon site :

Comme les paramètres pour le TLS se règlent sur le serveur et que j’ai une formule d’hébergement en serveur partagé, je ne peux rien faire. C’est étonnant de la part de OVH de ne pas être à la page sur leurs versions d’applications de cryptage SSL/TSL. Je me demande si ça vaut le coup de lancer un ticket pour ça.

↑ — Revenir au début

PS : Cet article est le premier que j’écris avec Gutenberg sur infodocbib.net. Je me suis fait la main sur un autre site auparavant. Merci le confinement 😉 !

Vous aimerez aussi :

• Pourquoi prendre un nom de domaine
• L’hermine et le dragon
• Avant de mettre en ligne un site fait main
• Tuto : Migrer / sauvegarder un site WordPress