Votre équipe de support est soudainement submergée de tickets concernant des erreurs « 421 Misdirected Request », et vous vous demandez si Internet a simplement un mauvais jour. Spoiler : ce n’est pas le cas. Mais Apache pourrait bien être en cause.
Décryptons ce qui se passe, pourquoi cela arrive maintenant, et comment le résoudre, que vous utilisiez Plesk, cPanel, ou que vous gériez votre propre configuration Apache.
Qu’est-ce qu’une erreur 421 SNI ?
L’erreur HTTP 421 « Misdirected Request » est la façon dont Apache dit :
« Je ne m’attendais pas à vous sur cette connexion. »
Cela se produit lorsque l’indication de nom de serveur (SNI) dans la poignée de main TLS ne correspond pas au nom d’hôte qu’Apache attend. En termes simples, Apache se trompe lorsqu’il reçoit une requête sans savoir quel site il doit servir, surtout lorsque plusieurs sites sont hébergés sur la même adresse IP.
Un bref historique de SNI
SNI a été introduit pour résoudre le problème d’hébergement de plusieurs sites HTTPS sur une seule adresse IP. Avant SNI, chaque site HTTPS nécessitait sa propre IP. Avec SNI, le client indique au serveur quel nom d’hôte il souhaite lors de la poignée de main TLS, permettant à Apache de servir le bon certificat et contenu.
Mais voici le hic : si le client (comme nginx) ne transmet pas correctement le nom d’hôte, Apache se fâche — d’où l’erreur 421.
Pourquoi cela se produit-il maintenant ?
Les récentes mises à jour d’Apache (notamment 2.4.64) ont introduit une gestion plus stricte de SNI pour corriger plusieurs failles de sécurité (CVE). Ces changements signifient qu’Apache refuse désormais de servir des requêtes qui n’incluent pas un en-tête SNI valide. C’est excellent pour la sécurité, mais cela cause aussi des problèmes.
CVE en coulisses
La mise à jour d’Apache a traité plusieurs CVE, notamment :
- CVE-2024-38474 : Gestion incorrecte de SNI dans les scénarios de proxy inverse
- CVE-2024-38475 : Confusion de nom d’hôte TLS menant à un potentiel MITM
- CVE-2024-38476 : Mauvaise orientation des requêtes dans les environnements multi-locataires
Comment confirmer que c’est la faute de l’hôte
Voici un test rapide en terminal pour voir si le problème vient du serveur Apache en remplaçant le domaine et l’IP de l’hôte par les vôtres :
curl -IkH 'host:domain.com' https://192.168.0.1
- Si vous obtenez un 421, le serveur ne gère pas correctement SNI.
- Si vous obtenez un 200, le problème est ailleurs.
Solutions pour l’erreur 421
Si vous utilisez Plesk
Plesk a publié des correctifs dans les versions 18.0.70.3 et 18.0.71.1. Si vous utilisez une version plus ancienne, vous pouvez la patcher manuellement en ajoutant ceci à votre configuration nginx :
proxy_ssl_server_name on;
proxy_ssl_name $host;
proxy_ssl_session_reuse off;
Puis redémarrez nginx :
systemctl restart nginx
Si vous utilisez cPanel
cPanel a temporairement annulé la mise à jour d’Apache dans ea-apache24-2.4.64-3 et recommande de mettre à jour via :
/scripts/upcp
Ou manuellement :
dnf update ea-* # AlmaLinux
yum update ea-* # CentOS
apt upgrade # Ubuntu
Si vous n’utilisez pas Plesk ou cPanel
Vous devrez vous assurer manuellement que votre proxy inverse (nginx, HAProxy, etc.) transmet les en-têtes SNI corrects. Dans nginx, cela signifie :
proxy_ssl_server_name on;
proxy_ssl_name $host;
proxy_ssl_session_reuse off;
Vérifiez également que vos hôtes virtuels Apache sont configurés avec les directives ServerName et ServerAlias qui correspondent aux noms d’hôte attendus.
Bonus : Ce que nous avons fait en interne
Notre équipe de sécurité a activé « force hostname over TLS » sur tous les sites utilisant notre WAF. Cela garantit que même si nous nous connectons directement à un serveur Apache mal configuré, nous envoyons toujours le bon SNI. C’est une approche ceinture et bretelles, et cela fonctionne bien jusqu’à présent.
Conclusion
C’est l’un de ces moments où une mise à jour de sécurité rencontre le chaos du monde réel. La solution est simple une fois que vous savez ce qui se passe, mais jusqu’à ce moment-là, c’est un vrai casse-tête. J’espère que cet article vous épargnera quelques heures de recherche dans les journaux et de tests curl.
En tant qu’expert en cybersécurité WordPress, je suis là pour vous aider.
- En cas d’urgence, nous proposons une analyse complète, le nettoyage des malwares, la suppression des backdoors et le renforcement de la sécurité.
- Pour la tranquillité au quotidien, notre service de maintenance inclut l’installation d’antivirus, les mises à jour régulières, les sauvegardes et une surveillance 24/7, avec option d’hébergement Premium en France.
- Pour booster votre visibilité, nous offrons des services d’optimisation SEO technique, de stratégie éditoriale et de création de contenus ciblés.
Besoin d’aide ? Contactez-moi pour sécuriser et optimiser votre site WordPress !
Catégories suggérées :
- Sécurité WordPress
- Hébergement web
- Maintenance WordPress
- Apache
