HTTPS WordPress : corriger contenu mixte et redirections

La plupart des problèmes d'HTTPS sous WordPress viennent d'une migration à moitié terminée, pas d'un certificat manquant. Le certificat est installé et la page d'accueil affiche un cadenas. Mais les articles montrent une icône d'avertissement, d'anciens liens http:// traînent dans le contenu, et un visiteur qui saisit example.com subit deux ou trois redirections avant d'arriver sur la vraie page. Ce guide règle cette situation dans un ordre sans risque.

HTTPS WordPress : le certificat n'est que la première étape

Commencez par mesurer. Ces deux commandes montrent le parcours réel du navigateur d'un visiteur :

curl -sI http://example.com
curl -sIL http://example.com | grep -iE '^(HTTP|location)'

La première commande affiche le code de statut et l'en-tête Location de la première réponse. La seconde suit toutes les redirections. Si vous voyez plus d'une 301 avant le 200 final, vous avez une chaîne de redirections. Ouvrez ensuite votre site dans le navigateur, appuyez sur F12 et regardez la console : c'est là qu'apparaissent les avertissements de contenu mixte.

Il faut aussi être clair sur ce que fait HTTPS. Il chiffre le trafic entre le navigateur et le serveur et empêche sa modification en transit. C'est l'une des mesures citées à l'article 32, paragraphe 1, point a) du RGPD, le chiffrement, pour les mots de passe de connexion, les formulaires de contact et les données de paiement. En revanche, HTTPS ne dit rien de la sécurité du site lui-même. Un site doté d'un certificat valide peut très bien faire tourner une extension vulnérable, héberger un malware ou avoir un compte administrateur protégé par password123. La place du chiffrement parmi les autres mesures de sécurité est détaillée dans l'article 32 du RGPD appliqué à WordPress.

Obtenir un certificat gratuit chez l'hébergeur ou via ACME

La plupart des panneaux d'hébergement européens proposent un certificat Let's Encrypt gratuit derrière un simple interrupteur, souvent sous « SSL/TLS » ou « Sécurité ». Activez-le et vérifiez qu'il couvre à la fois example.com et www.example.com. Un certificat qui ne vaut que pour un seul nom provoque des erreurs de navigateur sur l'autre, même si ce nom ne fait que rediriger.

Sur votre propre serveur, utilisez un client ACME. Certbot est le choix courant et met en place le renouvellement automatique :

sudo certbot --nginx -d example.com -d www.example.com
sudo certbot renew --dry-run

Remplacez --nginx par --apache si vous utilisez Apache. Le test à blanc vérifie que le renouvellement fonctionnera réellement. S'il échoue maintenant, il échouera aussi au prochain renouvellement réel.

Inutile de payer pour un certificat validé par domaine pour obtenir le cadenas. Un certificat payant se justifie pour un contrat de support ou des besoins de validation particuliers. Pour le chiffrement, un certificat gratuit est tout aussi solide.

Sauvegarder, puis changer l'adresse WordPress et l'adresse du site

Faites une sauvegarde de la base de données avant toute modification. Les étapes suivantes réécrivent des milliers de lignes, et la sauvegarde est votre bouton « annuler ». Des sauvegardes WordPress qui se restaurent vraiment explique comment en produire de fiables. Avec WP-CLI, une seule ligne suffit :

wp db export before-https.sql

Allez ensuite dans Réglages > Général et passez l'adresse WordPress (URL) et l'adresse du site (URL) de http:// à https://. Si WordPress est installé dans un sous-répertoire, conservez le chemin. Vous pouvez aussi le faire en ligne de commande :

wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'

Si les deux champs sont grisés, WP_HOME et WP_SITEURL sont définis dans wp-config.php. Modifiez alors les valeurs à cet endroit : les réglages du tableau de bord ne peuvent pas les remplacer.

Si vous êtes déconnecté et ne parvenez plus à vous reconnecter, par exemple parce que le certificat ne fonctionne pas encore, définissez temporairement WP_HOME et WP_SITEURL dans wp-config.php avec l'ancienne adresse http:// (ou remettez-les à l'ancienne valeur s'ils s'y trouvent déjà), ou lancez les deux commandes wp option update avec les anciennes valeurs. Réglez d'abord le certificat, puis recommencez.

Remplacer proprement les anciennes URL http:// avec wp search-replace

Vos articles, menus, widgets et options de thème contiennent encore des centaines de liens http://example.com. Ne les corrigez pas avec un REPLACE SQL brut. WordPress et de nombreuses extensions stockent leurs réglages sous forme de PHP sérialisé, qui enregistre la longueur de chaque chaîne, par exemple s:22:"http://example.com/img". Ajouter le « s » allonge la chaîne d'un caractère. La longueur enregistrée ne correspond plus, PHP ne peut plus lire la valeur, et des widgets, des mises en page de constructeur ou des réglages de thème disparaissent sans bruit.

[wp search-replace](https://developer.wordpress.org/cli/commands/search-replace/) désérialise les données, remplace le texte, puis les resérialise avec les bonnes longueurs. Lancez toujours d'abord un essai à blanc :

wp search-replace 'http://example.com' 'https://example.com' --all-tables --skip-columns=guid --dry-run

Lisez le nombre de remplacements par table. S'ils paraissent plausibles, relancez la même commande sans --dry-run. Quelques précisions :

• --skip-columns=guid laisse les GUID des contenus intacts. Ce sont des identifiants, pas des liens, et par convention on ne les modifie pas.
• --all-tables touche toutes les tables de la base. Si la base est partagée avec un autre site ou une autre application, utilisez plutôt --all-tables-with-prefix.
• Si votre hôte canonique est sans www, lancez un second remplacement de http://www.example.com vers https://example.com.
• Certains constructeurs de pages stockent du JSON avec des barres obliques échappées (http:\/\/example.com), que la recherche simple ne trouve pas. Faites un essai à blanc pour cette forme, ou utilisez l'outil de remplacement d'URL du constructeur.

Videz ensuite tous les caches : wp cache flush, votre extension de cache de pages, les éventuels caches serveur et le CDN. Régénérez les fichiers CSS du constructeur de pages si celui-ci le permet. Sans accès SSH, une extension de recherche-remplacement qui gère les données sérialisées, comme Better Search Replace, fait le même travail. Supprimez-la une fois terminé.

Une seule redirection 301 vers l'hôte HTTPS canonique

Choisissez une adresse canonique, avec ou sans www, et tenez-vous-y. Toutes les autres variantes doivent aller directement vers cette adresse par une seule redirection 301. Une chaîne du type http → https → www → final ralentit chaque première visite, gaspille les passages des moteurs de recherche et complique le diagnostic.

Apache, à placer au-dessus du bloc # BEGIN WordPress dans .htaccess :

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [L,R=301]

nginx :

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name www.example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    return 301 https://example.com$request_uri;
}

Gardez la redirection à un seul endroit. Si une extension, .htaccess et le CDN redirigent tous les trois, vous obtenez des chaînes ou des boucles. Choisissez le serveur ou le CDN et retirez les autres.

Boucles de redirection derrière un CDN ou un proxy inverse

La boucle classique vient du mode SSL « Flexible » de Cloudflare. Le navigateur parle HTTPS à Cloudflare, mais Cloudflare parle en HTTP simple à votre serveur. Le serveur voit du HTTP, redirige vers HTTPS, et le cycle recommence. Installez un certificat sur le serveur et réglez le mode sur Full (strict) dans les paramètres SSL/TLS de Cloudflare. Le trafic vers le serveur est alors chiffré et le certificat du serveur est vérifié.

D'autres proxys et répartiteurs de charge transmettent le schéma d'origine dans un en-tête X-Forwarded-Proto. WordPress ne le lit pas par défaut. Ajoutez ceci au-dessus de la ligne « stop editing » dans wp-config.php :

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https' ) {
    $_SERVER['HTTPS'] = 'on';
}

FORCE_SSL_ADMIN et la page de connexion

define( 'FORCE_SSL_ADMIN', true );

WordPress ne sert alors la page de connexion et le tableau de bord qu'en HTTPS. Les mots de passe et les cookies d'administration ne circulent jamais en clair, même si quelqu'un ouvre un vieux favori en http://. C'est un filet de sécurité, pas votre solution de redirection : cela ne change rien pour les pages publiques. Les autres réglages de wp-config.php sont traités dans Durcir wp-config.php : 10 réglages à vérifier.

Repérer le contenu mixte restant dans les outils de développement

On parle de contenu mixte quand une page HTTPS charge une ressource en HTTP. Les navigateurs bloquent les scripts et les cadres non sécurisés, et signalent ou mettent à niveau les images, d'où la disparition du cadenas. Ouvrez les outils de développement sur une page concernée. La console liste chaque requête non sécurisée avec son URL. Dans les navigateurs basés sur Chromium, saisissez scheme:http dans le filtre de l'onglet Réseau pour toutes les voir d'un coup.

Après un search-replace propre, les causes restantes se trouvent généralement hors de la base de données. Les sources typiques sont des URL codées en dur dans les fichiers du thème, des widgets HTML personnalisé, du CSS personnalisé (background: url(http://...)), des fichiers CSS de constructeur de pages et d'anciens contenus intégrés tiers. Pour les chercher dans le thème :

grep -rn "http://" wp-content/themes/your-theme/
wp db search 'http://example.com'

Corrigez le problème à la source. Les extensions qui réécrivent les URL à chaque chargement de page masquent le problème sans le résoudre, et cessent de fonctionner une fois désactivées. La directive CSP upgrade-insecure-requests peut servir de solution transitoire pendant le nettoyage. Elle est expliquée dans En-têtes de sécurité WordPress.

Ne vous limitez pas à la page d'accueil. Testez le tunnel de commande, le formulaire de contact, la page de connexion, un article, une archive de catégorie et toute page d'atterrissage construite avec un autre modèle.

Surveiller l'expiration du certificat, puis activer HSTS

Le renouvellement automatique peut échouer sans que personne ne s'en aperçoive. Les causes courantes : un changement de DNS, le passage à un nouveau CDN, ou une règle de pare-feu ou de redirection qui bloque /.well-known/acme-challenge/. Mettez en place une supervision externe qui contrôle le certificat et vous alerte au moins deux semaines avant son expiration. Beaucoup de services de supervision de disponibilité incluent ce contrôle. Pour lire vous-même la date d'expiration :

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -enddate

HSTS (RFC 6797) vient en dernier. Il indique aux navigateurs de n'utiliser que HTTPS : un certificat défaillant devient alors une erreur bloquante pour les visiteurs, et avec includeSubDomains, il en va de même pour tout sous-domaine oublié resté en HTTP seul. Ne l'activez que lorsque tous les sous-domaines et toutes les redirections fonctionnent, et commencez par un max-age court. Les valeurs et la mise en garde sur le preload sont détaillées dans En-têtes de sécurité WordPress.

L'extension d'audit de secaudit.eu contrôle les réglages de durcissement et de configuration, ainsi que l'intégrité des fichiers et les extensions obsolètes. Après la migration, vous disposez d'un relevé de l'état du site à conserver dans votre documentation. → secaudit.eu

Prochaine étape : lancez le contrôle de sauts curl -sIL sur les quatre variantes (http, http://www, https://www, https). Ouvrez ensuite vos cinq pages les plus importantes avec la console des outils de développement ouverte. Au plus une 301 par variante, un 200 direct sur l'URL HTTPS canonique et aucun message de contenu mixte : la migration est terminée.

FAQ

Un certificat gratuit suffit-il pour une boutique en ligne ?

Oui. Un certificat gratuit validé par domaine chiffre le trafic aussi solidement qu'un certificat payant. La sécurité de la boutique dépend de ses extensions, de ses mises à jour, de ses connexions et de sa configuration de paiement, pas du prix du certificat.

Pourquoi le cadenas disparaît-il sur certaines pages seulement ?

Ces pages chargent au moins une ressource en HTTP. Il s'agit le plus souvent d'une image, d'un script ou d'un contenu intégré provenant d'un widget, d'un modèle ou d'une section de constructeur de pages que les autres pages n'utilisent pas. La console des outils de développement, ouverte sur cette page, indique l'URL exacte.

HTTPS rend-il mon site conforme au RGPD ?

Non. HTTPS est une mesure technique au titre de l'article 32, le chiffrement en transit. Le RGPD attend aussi que vous sécurisiez les systèmes eux-mêmes, que vous puissiez rétablir les données après un incident, que vous testiez régulièrement vos mesures et que vous documentiez le tout.

Cet article est une information générale et ne constitue pas un conseil juridique.