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
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.
- Renouvellement immédiat et manuel du certificat manquant sur le sous-domaine d’administration, via
certbot certonly --nginx -d admin.exemple.fr. - Vérification du fichier de chaîne complète généré, avec
openssl s_clientcomme décrit plus haut, avant de considérer le renouvellement effectif. - Rechargement du service web pour prendre en compte le nouveau certificat, sans désactiver
FORCE_SSL_ADMINà aucun moment de la procédure. - 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 deFORCE_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.
