Pour activer (et forcer) l’utilisation de l’interface d’administration WordPress avec SSL
, il y a deux constantes que vous pouvez définir dans votre fichier wp-config.php
. Cela ne suffit pas de définir ces deux constantes dans un fichier d’extension ; elles doivent être définies dans votre fichier wp-config.php
. Vous devez aussi déjà avoir configuré SSL
sur le serveur et avoir un hôte virtuel (« virtual host ») configuré pour le serveur sécurisé avant que votre site fonctionne correctement avec ces constantes définies sur true
.
Note: FORCE_SSL_LOGIN
a été déprécié dans la Version 4.0. Veuillez utiliser FORCE_SSL_ADMIN
à la place.
Pour forcer les connexions SSL et l’accès administrateur SSL
La constante FORCE_SSL_ADMIN
peut être définie à true
dans le fichier wp-config.php
pour forcer toutes les connexions et toutes les sessions d’administration à se dérouler en SSL.
Exemple
define('FORCE_SSL_ADMIN', true);
Utiliser un Reverse Proxy
Si WordPress est hébergé derrière un proxy inverse (« reverse proxy ») qui fournit le SSL, mais qu’il est lui-même configuré sans SSL, ces options enverront initialement toutes les requêtes dans une boucle de redirection infinie. Pour éviter cela, vous devez configurer WordPress de sorte qu’il reconnaisse l’entête HTTP_X_FORWARDED_PROTO
(en supposant que vous avez configuré correctement le proxy inverse avec cet entête).
Exemple
define('FORCE_SSL_ADMIN', true);
// in some setups HTTP_X_FORWARDED_PROTO might contain
// a comma-separated list e.g. http,https
// so check for https existence
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false ) {
$_SERVER['HTTPS'] = 'on';
}
Informations complémentaires
Le reste de cet article sert d’information au cas où vous utilisez une ancienne version de WordPress (ce que vous ne devriez idéalement pas faire !) ou si votre configuration SSL est quelque peu différente (c’est-à-dire que votre certificat SSL est pour un domaine différent).
Parfois, vous souhaitez que l’ensemble de votre interface d’administration WordPress s’exécute via une connexion sécurisée utilisant le protocole https
. Conceptuellement, la procédure fonctionne comme ceci :
- Configurez deux hôtes virtuels avec la même URL (l’url du blog), l’un sécurisé, l’autre non.
- Sur l’hôte virtuel sécurisé, configurez une règle de réécriture qui transfère tout le trafic non-wp-admin vers le site non sécurisé.
- Sur l’hôte virtuel non sécurisé, configurez une règle de réécriture qui transfère tout le trafic vers wp-admin vers l’hôte sécurisé.
- Installez un filtre (via une extension) qui filtre les liens dans wp-admin afin qu’une fois activés, les liens administratifs soient réécrits pour utiliser
https
et qui édite les cookies pour qu’ils fonctionnent uniquement sur des connexions cryptées.
Le guide suivant concerne WordPress 1.5 et Apache exécutant mod_rewrite
, utilisant les règles de réécriture dans httpd.conf
(par opposition aux fichiers .htaccess
), mais pourrait facilement être modifié pour s’adapter à d’autres scénarios d’hébergement.
Hôtes virtuels (Virtual Hosts)
Vous avez besoin d’un hôte (virtuel) configuré pour le serveur sécurisé en plus du site non sécurisé. Dans cet exemple, l’hôte virtuel sécurisé utilise le même DocumentRoot
que l’hôte non sécurisé. Hypothétiquement, vous pourriez utiliser un hôte avec un nom différent, tel que wpadmin.mysite.com
et lier la racine du document au répertoire wp-admin
.
Veuillez demander à votre FAI de configurer un hôte virtuel sécurisé pour vous, ou si vous disposez d’un accès administratif, configurez le vôtre. Notez que vous ne pouvez pas utiliser l’hébergement virtuel basé sur le nom pour identifier différents serveurs SSL (lien externe en anglais).
Réécrire les règles pour l’hôte non sécurisé
Dans le paragraphe du .htaccess
ou hôte virtuel du fichier httpd.conf
pour votre hôte non sécurisé, ajoutez cette règle de réécriture pour accéder automatiquement à l’hôte sécurisé lorsque vous accédez à http://mysite.com/wp-admin/
ou http://mysite .com/wp-login.php
.
Cela devrait aller au-dessus du bloc principal de réécriture de WordPress.
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /(.*)\ HTTP/ [NC]
RewriteCond %{HTTPS} !=on [NC]
RewriteRule ^/?(wp-admin/|wp-login\.php) https://mysite.com%{REQUEST_URI}%{QUERY_STRING} [R=301,QSA,L]
Si vous utilisez des règles de réécriture de permalien, cette ligne doit précéder RewriteRule ^.*$ - [S=40]
.
Une idée importante dans ce bloc est d’utiliser THE_REQUEST
, qui garantit que seules les requêtes http
réelles sont réécrites et non les requêtes de fichiers directs locaux, comme une inclusion (include
) ou un fopen
.
Réécrire les règles pour l’hôte sécurisé (Facultatif)
Ces règles de réécriture sont facultatives. Elles désactivent l’accès au site public via une connexion sécurisée. Si vous souhaitez rester connecté à la partie publique de votre site en utilisant l’extension ci-dessous, vous ne devez pas ajouter ces règles, car l’extension désactive le cookie sur les connexions non cryptées.
L’hôte virtuel sécurisé doit avoir deux règles de réécriture dans un fichier .htaccess
ou dans la déclaration de l’hôte virtuel (voir Utiliser les permaliens pour en savoir plus sur la réécriture) :
RewriteRule !^/wp-admin/(.*) - [C]
RewriteRule ^/(.*) http://www.mysite.com/$1 [QSA,L]
La première règle exclut le répertoire wp-admin
de la règle suivante, qui déplace le trafic vers le site sécurisé vers le site non sécurisé, afin que les choses restent fluides et transparentes pour votre public.
Définir l’URI de WordPress
Pour que certaines extensions fonctionnent, et pour d’autres raisons, vous souhaiterez peut-être définir votre URI WordPress dans les options pour refléter le protocole https
en définissant ce paramètre https://mysite.com
. L’adresse de votre blog ne devrait pas changer.
Exemples de paragraphes de configuration
REMARQUE : la configuration ci-dessous n’est pas compatible à 100 % avec WordPress 2.8+, WordPress 2.8 utilise certains fichiers du dossier wp-includes
. La redirection introduite par le premier ensemble de règles de réécriture peut provoquer des avertissements de sécurité pour certains utilisateurs. Voir https://core.trac.wordpress.org/ticket/10079 pour plus d’information.
<VirtualHost nnn.nnn.nnn.nnn:443>
ServerName www.mysite.com
SSLEngine On
SSLCertificateFile /etc/apache2/ssl/thissite.crt
SSLCertificateKeyFile /etc/apache2/ssl/thissite.pem
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
DocumentRoot /var/www/mysite
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule !^/wp-(admin|includes)/(.*) - [C]
RewriteRule ^/(.*) http://www.mysite.com/$1 [QSA,L]
</IfModule>
...
</VirtualHost>
# Insecure site
<VirtualHost *>
ServerName www.mysite.com
DocumentRoot /var/www/ii/mysite
<Directory /var/www/ii/mysite >
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^wp-admin/(.*) https://www.mysite.com/wp-admin/$1 [C]
RewriteRule ^.*$ - [S=40]
RewriteRule ^feed/(feed|rdf|rss|rss2|atom)/?$ /index.php?&feed=$1 [QSA,L]
...
</IfModule>
</Directory>
...
</VirtualHost>
Réécriture pour la connexion et l’inscription
C’est évidemment une bonne idée d’utiliser SSL pour les connexions et les enregistrements des utilisateurs. Considérez les RewriteRules
de remplacement suivantes.
Non sécurisé
RewriteRule ^/wp-(admin|login|register)(.*) https://www.mysite.com/wp-$1$2 [C]
Sécurisé
RewriteRule !^/wp-(admin|login|register)(.*) - [C]
Réécriture pour les sites appelés sur le port 443 ou le port 80
Résumé
Cette méthode ne résout pas certains risques inhérents de sécurité (en anglais) dans WordPress, et ne vous protège pas non plus contre les attaques de type man-in-the-middle
ou d’autres risques susceptibles de paralyser les connexions sécurisées.
Cependant, cela devrait rendre beaucoup plus difficile pour une personne malveillante de voler vos cookies et/ou vos en-têtes d’authentification et de les utiliser pour usurper votre identité et accéder à wp-admin
. Cela complique également la possibilité de détecter votre contenu, ce qui pourrait être important pour les blogs juridiques qui peuvent contenir des brouillons de documents nécessitant une protection stricte.
Vérification
Sur le serveur de l’auteur, les journaux indiquent que les requêtes GET
et POST
sont effectuées via SSL
et que tout le trafic vers wp-admin
sur l’hôte non sécurisé est transféré vers l’hôte sécurisé.
Exemple de ligne de log d’un POST :
[Thu Apr 28 09:34:33 2005] [info] Subsequent (No.5) HTTPS request received for child 6 (server foo.com:443)
xx.xxx.xxx.xxx - - [28/Apr/2005:09:34:33 -0500] "POST /wp-admin/post.php HTTP/1.1" 302 - "https://foo.com/wp-admin/post.php?acti
on=edit&post=71" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3"
Des tests supplémentaires, de préférence avec un renifleur de paquets (« packet sniffer ») et des outils d’analyse de réseau approfondis, aideraient à confirmer.
Limitations
L’auteur suppose (mais n’a pas vérifié) que si l’utilisateur a stocké des cookies ou a demandé à son navigateur de mémoriser les mots de passe (non basés sur les champs de formulaire mais s’il utilise certains mécanismes d’authentification externes) et clique sur http://www.mysite.com/ wp-admin/
, ces paquets sont envoyés en clair et les en-têtes cookie/auth pourraient être interceptés. Par conséquent, pour garantir une sécurité maximale, l’utilisateur doit utiliser explicitement l’hôte https
ou toujours se connecter au début de nouvelles sessions.
Traduit par Fredde Battel
Relu par Jenny Dupuy & Pierre Lannoy
Dernière mise à jour le 26 janvier 2025