# FORCE_SSL_ADMIN et un certificat expiré rendent wp-admin injoignable > Le site public répond normalement, mais wp-admin renvoie une erreur de sécurité bloquante. Diagnostic d'un piège classique quand une constante de configuration entre en conflit avec un certificat expiré. - Auteur : WordPress Développement - Publié le : 2023-07-05 - Mis à jour le : 2023-07-05 - Catégorie : Hébergement & serveurs - URL : https://www.wpmoderne.fr/hebergement/force-ssl-admin-certificat-expire-wp-admin-injoignable/ ## L’essentiel - Distinguer une erreur de certificat d'un vrai blocage applicatif - Vérifier wp-config.php avant de suspecter le serveur - Ne jamais désactiver FORCE_SSL_ADMIN comme solution définitive `NET::ERR_CERT_DATE_INVALID` sur `/wp-admin/`, alors que la page d'accueil du même site s'affiche sans le moindre avertissement dans le même navigateur, à la même seconde. Ce comportement, en apparence contradictoire, correspond à un piège précis et récurrent : la présence de la constante `FORCE_SSL_ADMIN` définie à `true` dans `wp-config.php`, combinée à un certificat TLS qui vient d'expirer sur un sous-domaine spécifique de l'administration. Le renouvellement automatique du certificat lui-même, et les raisons pour lesquelles il a échoué silencieusement, ne sont pas traités dans ce diagnostic : l'objet ici est de comprendre pourquoi seul `wp-admin` devient inaccessible pendant que le reste du site continue de fonctionner, et comment rétablir l'accès sans exposer l'interface d'administration en clair. ## Symptôme : un blocage strictement limité à l'administration Le site public, servi par le nom de domaine principal, continuait de répondre normalement, certificat valide affiché sans avertissement. Seule la zone d'administration, accessible via un enregistrement DNS distinct pointant vers une adresse IP différente pour des raisons de séparation d'infrastructure, renvoyait une erreur de certificat bloquante, empêchant toute connexion de l'équipe éditoriale. ## Diagnostic : remonter à la source de la contrainte > L'essentiel à retenir : Distinguer une erreur de certificat d'un vrai blocage applicatif ; Vérifier wp-config.php avant de suspecter le serveur ; Ne jamais désactiver FORCE_SSL_ADMIN comme solution définitive La constante `FORCE_SSL_ADMIN`, définie dans `wp-config.php`, force WordPress à rediriger systématiquement toute requête vers `wp-admin` en HTTPS, y compris si l'utilisateur tente d'y accéder en HTTP. Ce comportement, généralement souhaitable pour la sécurité, devient un piège lorsque le certificat associé au nom de domaine ou sous-domaine effectivement utilisé pour l'administration a expiré : la redirection forcée vers HTTPS se heurte alors à un certificat invalide, sans aucune possibilité de contournement en HTTP, WordPress refusant lui-même toute connexion non chiffrée dès que cette constante est active. ``` // Extrait de wp-config.php identifié comme source du blocage define( 'FORCE_SSL_ADMIN', true ); ``` Une vérification complémentaire, avec `openssl s_client -connect admin.exemple.fr:443 -servername admin.exemple.fr`, a confirmé que le certificat présenté sur ce sous-domaine précis avait expiré trois jours plus tôt, alors que le certificat du domaine principal, renouvelé séparément par un processus distinct, restait parfaitement valide. ### Pourquoi les deux certificats avaient divergé L'architecture du site utilisait un sous-domaine dédié pour `wp-admin`, avec son propre certificat généré indépendamment de celui du domaine principal. Le script de renouvellement automatique, configuré uniquement pour le domaine principal lors d'une intervention antérieure, ne couvrait pas ce sous-domaine spécifique, laissé de côté sans que personne ne s'en aperçoive avant l'expiration effective. ## Correctif immédiat : rétablir l'accès sans tout désactiver La tentation la plus fréquente, face à ce blocage, consiste à commenter purement et simplement la ligne `FORCE_SSL_ADMIN` dans `wp-config.php` pour débloquer l'accès dans l'urgence. Cette solution fonctionne, mais rouvre l'administration en HTTP non chiffré, exposant les identifiants de connexion en clair sur le réseau le temps que la constante reste désactivée. 1. Renouvellement immédiat et manuel du certificat manquant sur le sous-domaine d'administration, via `certbot certonly --nginx -d admin.exemple.fr`. 2. Vérification du fichier de chaîne complète généré, avec `openssl s_client` comme décrit plus haut, avant de considérer le renouvellement effectif. 3. Rechargement du service web pour prendre en compte le nouveau certificat, sans désactiver `FORCE_SSL_ADMIN` à aucun moment de la procédure. 4. Ajout explicite du sous-domaine d'administration dans le script de renouvellement automatique existant, corrigeant la cause racine plutôt que le seul symptôme. ## Prévention : superviser chaque nom couvert, pas uniquement le principal Une supervision de certificat mise en place uniquement sur le domaine principal ne détecte jamais ce type d'incident, puisque ce domaine reste valide pendant toute la durée du problème. La correction durable consiste à surveiller individuellement chaque nom d'hôte utilisé par le site, y compris les sous-domaines techniques rarement visités directement par un humain, comme celui dédié à l'administration. - Lister explicitement tous les noms d'hôte couverts par des certificats distincts sur l'infrastructure du site. - Configurer une alerte de supervision pour chacun d'eux, avec un seuil déclenché quinze jours avant expiration. - Vérifier également `FORCE_SSL_LOGIN`, souvent définie aux côtés de `FORCE_SSL_ADMIN`, qui provoque un blocage identique sur la seule page de connexion si elle est configurée séparément. > Un repère qu'on retient de cet incident : une constante de sécurité qui bloque un accès n'est jamais le bon endroit à corriger en premier. Le bon réflexe consiste à corriger ce qui a réellement expiré, et à ne toucher à la constante de sécurité que si le problème persiste après ce correctif. ## En résumé `FORCE_SSL_ADMIN` ne cause jamais, en soi, une expiration de certificat : elle se contente d'appliquer strictement une exigence de chiffrement déjà présente, révélant brutalement un certificat expiré qui serait resté invisible en HTTP. Le bon réflexe face à ce blocage consiste à corriger le certificat manquant, jamais à désactiver la constante, et à étendre la supervision à chaque sous-domaine réellement utilisé par le site, au-delà du seul nom de domaine public.