web-dev-qa-db-fra.com

421 Demande mal acheminée

J'obtiens parfois l'erreur 421 suivante:

Demande mal dirigée

Le client a besoin d'une nouvelle connexion pour cette demande car le nom d'hôte demandé ne correspond pas à l'indication de nom de serveur (SNI) utilisée pour cette connexion.

Cependant, l'actualisation du navigateur efface l'erreur et la page se charge normalement. Le prochain chargement de la page ne produira pas d'erreur et en tant que tel, le modèle semble assez aléatoire. Le seul modèle que je peux voir est que cela peut se produire lorsque je redirige une page en utilisant l'en-tête ("Location:". $ Url);

J'ai un certificat multi-domaine PositiveSSL de Comodo. Mes serveurs sont Apache sur un service d'hébergement Web partagé donc je n'ai pas accès à la configuration.

Je charge des pages d'un domaine et dans la page sont des liens vers un deuxième domaine sur le certificat.

Tout ce que j'ai lu concernant cette erreur semble indiquer que ce problème est lié au fait qu'il s'agit d'un certificat multi-domaine.

Ce que je voudrais savoir, c'est s'il y a quelque chose sur le côté du codage de la page Web (php) qui peut provoquer cela (et peut être corrigé) ou s'il s'agit d'une erreur de configuration ou éventuellement d'une erreur de serveur et seul mon service d'hébergement peut répare le.

Mon service d'hébergement n'a jusqu'à présent pas été en mesure de fournir quoi que ce soit et a demandé à être rappelé avec l'heure exacte à laquelle il se produirait afin de pouvoir le rechercher. Toute aide serait appréciée car je ne suis pas trop confiant qu'ils peuvent le comprendre.

[~ # ~] mise à jour [~ # ~] D'accord, presque deux ans plus tard et a décidé qu'il était temps de s'en occuper. J'ai pu résoudre la plupart des problèmes en supprimant mes domaines statiques qui servaient des images et du javascript. Cependant, j'utilisais toujours un deuxième domaine pour une partie de ce contenu et Safari en particulier me posait toujours des problèmes.

J'ai fait plus de recherches et suis tombé sur un autre article qui en parle ici . Exactement ce que décrit @Kevin. L'article a confirmé que cela se produit dans Safari. Donc, en suivant les conseils, j'ai décidé d'obtenir des certificats séparés pour chaque domaine. Je suis sur un hôte partagé (Webhostinghub) et j'ai découvert qu'ils offrent maintenant SSL gratuit (AutoSSL) qui se renouvelle automatiquement. Cela semblait trop beau pour être vrai. Ils m'ont mis en place avec 5 certificats gratuits. Jusqu'ici tout va bien. Je peux même essayer de réactiver les domaines statiques à tester. Si tout cela fonctionne, je vais économiser $ pour démarrer en bonus et laisser mes certificats Comodo expirer en juillet.

sslapache-2.4https
10
mseifert

Cela est dû à la séquence d'événements suivante:

  1. Le serveur et le client prennent en charge et utilisent HTTP/2.
  2. Le client demande une page à foo.example.com.
  3. Lors de la négociation TLS, le serveur présente un certificat valable pour les deux foo.example.com et bar.example.com (et le client l'accepte). Cela pourrait être fait avec un certificat générique ou un certificat SAN.
  4. Le client réutilise la connexion pour faire une demande de bar.example.com.
  5. Le serveur ne peut pas ou ne veut pas prendre en charge la réutilisation des connexions interdomaines (par exemple parce que vous avez configuré leur SSL différemment et Apache veut forcer une renégociation TLS) et sert HTTP 421.
  6. Le client ne réessaye pas automatiquement avec une nouvelle connexion (voir par exemple bogue Chrome # 546991 , maintenant corrigé). Le RfC pertinent dit que le client PEUT réessayer, pas qu'il DEVRAIT ou DOIT. Ne pas réessayer n'est pas particulièrement convivial, mais peut être souhaitable pour un outil de débogage ou une bibliothèque HTTP.

L'événement # 6 est hors de votre contrôle, mais selon le logiciel du serveur, # 5 peut être réparable. Consultez la documentation HTTP/2 de votre serveur pour plus d'informations sur comment et quand il envoie HTTP 421. Alternativement, vous pouvez émettre des certificats séparés pour chaque domaine, mais cela crée plus de surcharge administrative et peut ne pas en valoir la peine. Vous pouvez également désactiver complètement HTTP/2, mais c'est probablement exagéré dans la plupart des cas.

13
Kevin

Peut-être que cela sera utile à quelqu'un.

J'ai eu cette erreur lorsque j'ai essayé de changer ma configuration d'hôte virtuel Apache en HTTPS, mais j'ai seulement changé le port de 80 en 443 et j'ai oublié d'ajouter

   SSLEngine on
   SSLCertificateFile "/opt/lampp/htdocs/localhost.crt"
   SSLCertificateKeyFile "/opt/lampp/htdocs/localhost.key"

Configuration provoquant l'erreur 421:

<VirtualHost mydoamin.local:443>   <-- fistly I 
       DocumentRoot "/opt/lampp/htdocs/mydomain/"
       ServerName www.mydomain.local
</VirtualHost>

La configuration correcte:

<VirtualHost mydoamin.local:443>
       DocumentRoot "/opt/lampp/htdocs/mydomain/"
       ServerName www.mydomain.local
       SSLEngine on
       SSLCertificateFile "/opt/lampp/htdocs/localhost.crt"
       SSLCertificateKeyFile "/opt/lampp/htdocs/localhost.key"
</VirtualHost>
1
Radek Daniluk