Certificat SSL Let’s Encrypt sur un VPS Plesk

Certificat SSL Let’s Encrypt sur un VPS Plesk

Je n’ai plus de VPS Plesk depuis un bout de temps. Je laisse cet article en ligne pour information mais je ne pourrai pas répondre aux questions éventuelles.
Nous avons déjà vu comment transformer un site http en site https dans l’article migration d’un site WordPress en http vers https (SSL). Ici nous allons voir comment faire dans un hébergement Plesk VPS Classic de chez OVH. Il y a de petites différences avec un site d’un hébergement mutualisé OVH.

L’intérêt de passer en https

J’invite tous les anglophones à lire attentivement cet article de Wired. Il explique bien pourquoi tous les propriétaires de site devraient immédiatement chercher à passer leurs sites en https. Mais il va plus loin en montrant l’importance de l’interface utilisateur pour que les internautes comprennent les risques pris lorsqu’ils intéragissent avec un site non crypté. Le témoignage de l’Iranien est particulièrement édifiant.

https://www.wired.com/2016/11/googles-chrome-hackers-flip-webs-security-model/

Obtenir un certificat SSL Let’s encrypt

La documentation de Plesk est incomplète sur ce sujet, mais le processus est très simple.

Il suffit de cliquer sur le lien « Let’s Encrypt » :

Plesk : obtenir un certificat gratuit Let's Encrypt

Pour les réglages, je coche « inclure www.domaine.com » même si je redirige www sur la version sans préfixe (attention ça n’est pas coché dans la copie d’écran ci-dessous mais il faut le faire) :

Plesk : régler le certificat gratuit Let's Encrypt

 

Une fois qu’on a cliqué sur « installer », on a au bout de quelques secondes un message en vert disant que le certificat est installé.

Transformer un site en HTTPS

On peut suivre les instructions, à partir de l’étape 2 de l’article initial  migration d’un site WordPress en http vers https (SSL).

le contenu à ajouter dans .htaccess fonctionne aussi dans Plesk.

Et maintenant ?

Il faut vérifier que les redirections fonctionnent correctement. Un internaute doit pouvoir taper les url suivantes et être dirigé vers le site https://mon-domaine.com  :

  • www.mon-domaine.com
  • mon-domaine.com
  • http://mon-domaine.com
  • mon-domaine.com/wp-login.php (ou wp-admin.php)

Une fois ces vérifications faites, ça y est, on a un site moderne et sécurisé.

Check-list de vérification sécurité et SEO d’un site WordPress

Check-list de vérification sécurité et SEO d’un site WordPress

A la création d’un site, il est indispensable de vérifier la sécurité et l’indexabilité du site WordPress. C’est également indispensable après le transfert d’un site vers un nouvel hébergement. Cette check_list contient des éléments applicables à tout site WordPress et des actions spécifiques au transfert vers un hébergement d’un VPS Plesk. Cet article fait partie de la série .

Vérification de la sécurité

(1) sécuriser tout ce qui peut l’être avec WordPress Toolkit.

Avec Plesk, on dispose du WordPress Toolkit.

Sécuriser un site avec le WordPress Toolkit de Plesk

Sécuriser un site avec le WordPress Toolkit de Plesk

Après avoir cliqué sur « analyser la sécurité », je donne l’autorisation de sécuriser tout ce qui ne l’est pas.

Nota : selon cet article sur Devblog.Plesk, les changements ne sont pas faits en modifiant .htaccess (et n’en lit même pas le contenu pour définir le statut de sécurité). C’est la configuration du serveur web qui est modifiée. Toute modification du .htaccess va remplacer la configuration serveur correspondante.

(2) utiliser toutes les fonctionnalités de Sucuri

J’utilise l’extension gratuite « Sucuri Security – Auditing, Malware Scanner and Hardening » pour la sécurité du site. Les modifications qui suivent sont réalisées avec cette extension.

  • Exécuter tous les « hardening » proposés sauf  « website firewall protection » (pas dans la version gratuite de sucuri) et « error logs » qui « can not be determined ». Attention, je n’ai jamais essayé de voir si Sucuri peut changer correctement le préfixe de base de données. J’ai procédé comme indiqué dans l’article Changer le préfixe de base de données WordPress.
  • Dans Settings / Général (ou par une console d’erreur comme Query Monitor), j’ai eu une erreur indiquant que Sucuri n’a plus l’autorisation de stocker les données de Sucuri dans /home/parcoursz/www/wp-content/uploads/sucuri. Au final pour corriger le problème, il suffit de désactiver Sucuri, supprimer les fichiers stockés dans wp-content/uploads/sucuri puis réactiver Sucuri.

(3) Modifier wp-config.php

  • Vérifier que Sucuri a ajouté define( ‘DISALLOW_FILE_EDIT’, true );  pour interdire la modification de fichiers à partir du tableau de bord WordPress ;
  • En profiter pour ajouter une instruction pour limiter le nombre de versions stockées pour un article ou une page : define( ‘WP_POST_REVISIONS’, 5 );

(4) Ajuster .hataccess

Normalement c’est inutile pour un site monosite. Pour un site multisite, il faudra l’ajuster, mais ce sera l’objet d’un autre article.

Vérification pour le SEO

Après la création d’un site ou son transfert, il faut vérifier quelques points essentiels pour que le site reste correctement indexé par les moteurs de recherche :

(5) Google analytics

  • Vérifier que l’identifiant google analytics du site est toujours correctement défini. Pour moi c’est dans le menu « Insight » puisque j’utilise l’extension « Google Analytics par MonsterInsights« 
  • Vérifier que Google Analytics et Google for Webmasters nous considèrent toujours comme propriétaire du site : j’ai laissé un enregistrement TXT contenant un code de vérification Google dans les enregistrements DNS sur OVH (cf l’article Réglages DNS d’un hébergement tiers à domaines gérés par OVH). En principe il n’y a pas de problème mais il vaut mieux vérifier car on peut avoir oublié de transférer un fichier html de vérification ou ne pas avoir défini l’enregistrement TXT.

(6) Yoast SEO

  • Vérifier que les réglages de l’extension sont correctement faits ;
  • Vérifier que la connexion à la search console est faite correctement ;
  • Si les sitemaps dans google for webmasters ne sont pas récents, les soumettre à nouveau ;
  • Dans Google for Webmasters, regarder les erreurs d’exploration et les corriger (redirection) ;
  • Dans un site nouvellement créé, on vérifiera aussi que l’on a correctement rempli les extraits SEO pour l’ensemble des contenus.

(7) vitesse du site

  • Tester le site avec Google Test My Site puis corriger les défauts éventuels. Ce site teste l’ergonomie sur appareil mobile, la vitesse sur mobile et la vitesse sur ordinateur.

Changer le préfixe de base de données WordPress

Changer le préfixe de base de données WordPress

Avec WordPress, une bonne pratique de sécurité est d’utiliser un préfixe de base de données différent du préfixe par défaut. Celà complique en effet la tâche d’éventuels pirates.

Le préfixe par défaut de WordPress est « wp_ ». On peut le changer lors de l’installation de WordPress ou plus tard. Nous allons voir dans cet article comment changer le préfixe d’un site existant.

Attention, ce changement nécessite une bonne compréhension du fonctionnement d’une base de données pour WordPress. On peut casser un site internet si on le fait mal.

Il faut sauvegarder la base de données avant tout changement.

Ce tutoriel s’applique aux installation WordPress classiques. Pour une installation multisite, suivre les instructions de cet article de WPmuDev.

Changer le préfixe des tables

Quel préfixe choisir ?

L’idéal est d’utiliser 6 à 10 caractères composés de lettres minuscules ou majuscules et de chiffres, tel que p7fQ25Hg_ ou i9s5c0Fu1P_. Pour le créer, l’idéal est d’utiliser lastpass password generator, en n’oubliant pas d’ajouter « _ » à la fin du préfixe généré. 

Avec phpMyAdmin :

  1. Sauvegarder la base de données ;
  2. Remplacer le préfixe de table : en sélectionnant toutes les tables (tout cocher) puis « remplacer le préfixe de table ».
WordPress : changer le préfixe de base de données (2)

WordPress : changer le préfixe de base de données (2)

 

Et voilà, le préfixe des tables de notre base de données est devenu « newprefix_ ». A ce stade, notre site ne fonctionne plus du tout ! En effet, on n’a pas encore « dit » à WordPress que le préfixe de tables a changé.

Modifier wp-config.php

On édite wp-config.php pour que la ligne :

$table_prefix = 'wp_';

devienne

$table_prefix = 'newprefix_';

Après enregistrement du fichier modifié, les internautes peuvent de nouveau accéder au site. Mais l’accès au tableau de bord reste bloqué. 

Changer le préfixe de certains contenus des tables

Le préfixe de table est également utilisé à l’intérieur de certaines tables. C’est le cas de certains contenus du champ option_name de la table « newprefix_options », et du champ meta_key dans la table « newprefix_usermeta ».

Modifier les « option_name » avec l’ancien préfixe

La commande SQL pour afficher les lignes concernées, de la table « newprefix_options » est :

SELECT * FROM `newprefix_options` WHERE `option_name` LIKE '%wp_%'

On peut aussi le faire dans l’interface graphique de phpMyAdmin.

On obtient une liste d’éléments de la table qui contiennent wp_. Mais attention, bon nombre de lignes ne doivent pas être modifiées. Pour le site dont je réalise la modification en écrivant ce tutoriel, j’ai obtenu 78 lignes dans lesquelles ‘option_name’ est « LIKE » ‘wp_’. En fait, la seule à modifier (à la main) est wp_user_roles  qui devient newprefix_user_roles .

Modifier les meta_key avec l’ancien préfixe

La commande SQL pour afficher les lignes concernées, de la table « newprefix_usermeta » est :

SELECT * FROM `newprefix_usermeta` WHERE `meta_key` LIKE '%wp_%'

Pour s’y retrouver, on ordonne la colonne « meta_key » puis on modifie, à la main, toutes les entrées pour lesquelles la valeur de « meta_key » commence par wp_. En général on trouve les valeurs suivantes, autant de fois qu’il y a d’utilisateurs enregistrés pour le site :

  • wp_capabilities
  • wp_dashboard_quick_press_last_post_id
  • wp_media_library_mode
  • wp_user-settings
  • wp_user-settings-time
  • wp_user_level

A ce stade, on vérifie que tout va bien en se connectant au tableau de bord du site modifié. Si tout va bien, on arrive à se connecter et on a terminé.

En cas de problèmes

Cet article de WPmuDev, donne quelques pistes si on observe des dysfonctionnements après le changement de préfixe.

Problème n° 1 : pas d’accès au site

Lorsqu’on met l’adresse du site dans un navigateur, on arrive à un écran nous proposant d’installer WordPress !

La solution est de modifier wp-config.php pour que la ligne $table_prefix = ‘newprefix_’; contienne la bonne valeur du nouveau préfixe.

Problème n°2 : les utilisateurs n’ont plus la permission de se connecter au site

Dans ce cas, on a omis de modifier une ou plusieurs entrées de la table « newprefix_usermeta » et certaines valeurs de « meta_key » contiennent toujours le préfixe « wp_ ». Il faut donc vérifier ce que l’on a fait.

Notre problème n’est pas résolu ?

Voir l’article How to Fix “Error Establishing Database Connection” for WordPress. Il arrive en particulier que des extensions mal codées utilisent uniquement le préfixe par défaut « wp_ ». Dans ce cas, elles ne peuvent plus fonctionner une fois le préfixe changé. Pour les identifier, on désactive toutes les extensions puis on les réactive une à une jusqu’à ce que le site casse. Une fois l’extension problématique identifiée, on la supprime. On peut aussi revenir à la copie de la base de données réalisée avant le changement.

paramétrer wp-config.php

paramétrer wp-config.php

Le fichier wp-config.php dit à WordPress quels sont ses principaux réglages lorsqu’il démarre. Les éléments minimaux sont : la manière d’accéder à la base de données et le chemin d’accès au répertoire contenant WordPress. Mais d’autres éléments sont utiles ou indispensables.  (suite…)