Si votre site web derrière Deflect rencontre des erreurs HTTP de type 421, 403 ou 400, il est possible que vous ayez affaire à un problème de SNI. Cet article a pour but de vous guider dans la résolution de ce problème.
1. Qu’est-ce que le SNI ? #
L’indicateur de nom de serveur (SNI) est une extension du protocole TLS (Transport Layer Security) qui indique le nom d’hôte auquel le client tente de se connecter au début du processus d’échange.
Cela permet à un serveur de présenter plusieurs certificats sur la même adresse IP et le même numéro de port, et donc à plusieurs sites web HTTPS sécurisés d’être servis à partir de la même adresse IP sans qu’il soit nécessaire que tous ces sites utilisent le même certificat.
2. SNI et en-tête d’hôte HTTP #
L’en-tête HTTP host est également utilisé pour indiquer le site qu’un client tente d’atteindre. Mais il n’est pas envoyé après l’établissement de la connexion SSL.
En d’autres termes, SNI et l’en-tête HTTP host permettent tous deux au client de spécifier le nom du serveur qu’il tente d’atteindre. Cependant, SNI permet à cette information d’être présente plus tôt dans le processus de configuration de SSL, ce qui est crucial lorsque plusieurs sites web SSL partagent une même adresse IP.
Tous les serveurs web n’exigent pas l’alignement du nom SNI et de l’en-tête HTTP Host. Dans les cas où ils ne correspondent pas, l’en-tête HTTP Host a généralement la priorité. Cependant, certains serveurs web, tels qu’Apache, ont récemment commencé à exiger une correspondance entre le nom SNI et le nom d’hôte HTTP, créant ainsi un problème de SNI.
3. Identifier le problème des SNI #
Il se peut que vous soyez confronté à un problème de connexion SNI, si votre site web protégé par Deflect rencontre l’erreur HTTP suivante :
- 421 Demande mal adressée
Ou bien vous rencontrez l’erreur suivante , en partie ou en totalité :
- 403 Interdit
- 400 Mauvaise demande
Et l’une des conditions ci-dessous s’applique à vous :
- Vous avez récemment mis à jour votre serveur web d’origine
- Vous avez récemment mis à jour la configuration de votre serveur web d’origine
- Vous utilisez Apache comme serveur d’origine
- Vous hébergez plusieurs hôtes virtuels sur un seul serveur d’origine
3.1. Inspecter le journal du serveur web #
Examinez le journal de votre serveur web d’origine pour y trouver d’éventuels messages d’erreur. Par exemple, si vous voyez le message suivant dans le journal des erreurs d’Apache, cela indique que vous êtes confronté à un problème de SNI.
AH02032: Hostname example.com provided via SNI and hostname www.example.net provided via HTTP are different3.2. Connexion directe au serveur d’origine #
Vérifiez si vous rencontrez un problème de SNI parce que votre site web est situé derrière le reverse-proxy de Deflect Nginx.
Gardez à l’esprit qu’il n’est pas nécessaire de désactiver Deflect de manière universelle pour effectuer ce test. Au lieu de cela, vous pouvez facilement exécuter la commande cURL suivante pour forcer la résolution DNS vers l’IP de votre serveur d’origine.
curl --resolve <domain name>:443:<origin server IP> -k "https://<domain name>"Si vous ne parvenez pas à exécuter la commande cURL, vous pouvez modifier votre fichier local /etc/hosts (ou C:\NWindows\NSystem32\Ndrivers\Netchosts pour les utilisateurs de Windows). Cela vous permet d’obliger manuellement un nom de domaine à se résoudre à l’IP de votre serveur d’origine. N’oubliez pas d’annuler la modification une fois les tests terminés.
3.3. Serveur d’origine Apache #
Le 10 juillet 2025, Apache a publié la version 2.4.64, qui contient des correctifs de sécurité spécifiques concernant la gestion des SNI. Fondamentalement, cette nouvelle mise à jour rejettera une connexion si le nom SNI dans le paquet de liaison Secure Sockets Layer (SSL) ne correspond pas à l’en-tête Host dans le paquet HTTP de cette connexion SSL particulière. Voir le journal des modifications d’Apache.
Les sites web utilisant Nginx comme proxy inverse et Apache comme serveur d’origine sont concernés par cette mise à jour. En effet, dans une configuration de proxy inverse, Nginx ne relaie pas par défaut le nom SNI au serveur d’origine.
4. Résolution du problème des SNI #
4.1. Vérifiez si SNI est activé pour votre site web #
Deflect active automatiquement le SNI pour les sites web signés à partir de fin 2024. Mais cette fonction peut être désactivée manuellement par notre équipe de support. Pour vérifier si cette fonctionnalité est activée ou non pour votre site web, vous pouvez vous connecter au tableau de bord de Deflect, et localiser ces paramètres sous Paramètres -> Server Name Indication (SNI).
Dans la plupart des cas, il est conseillé de laisser ces paramètres activés, et ce n’est que dans de rares circonstances que vous devrez les désactiver. Toutefois, si le problème persiste même après avoir activé SNI, vous pouvez envisager de désactiver la réutilisation des sessions SSL.
4.2. Désactiver la réutilisation des sessions SSL #
Par défaut, Deflect réutilise la session SSL dans le pool de connexion sur le serveur d’origine identique pour l’optimisation. Cependant, si votre serveur d’origine héberge plusieurs hôtes virtuels avec des noms de domaine différents, la désactivation de la réutilisation de la session SSL peut résoudre l’erreur SNI mismatch.
Dans le tableau de bord de Deflect, vous pouvez localiser cette fonctionnalité sous Labs -> Désactiver la réutilisation de la session SSL.
4.3. Hôtes virtuels multiples #
Si vous exploitez plusieurs hôtes virtuels sur la même adresse IP d’origine sous Deflect, il est conseillé de revoir la configuration des serveurs web respectifs, et d’activer à la fois SNI et la désactivation de la réutilisation de la session SSL sur tous ces hôtes virtuels.
4.4. Domaines www #
Si votre site web utilise à la fois le domaine apex et le domaine www, ce dernier étant automatiquement ajouté par Deflect et mandaté vers la même IP d’origine, envisagez d’ajouter le nom de domaine www dans le nom de votre serveur dans la configuration de votre serveur web.
4.5. S’assurer que le nom commun du certificat d’origine correspond au nom d’hôte #
Vous voudrez peut-être vous assurer que le nom commun (CN) du certificat SSL sur votre serveur d’origine correspond au nom d’hôte demandé par le visiteur. Vous pouvez le vérifier en vous connectant directement à votre serveur d’origine à l’aide de cURL.
curl --resolve <domain name>:443:<origin server IP> -k "https://<domain name>" -v -IRecherchez CN= dans le résultat, par exemple :
* Added example.com:443:203.0.0.0 to DNS cache
* Hostname example.com was found in DNS cache
* Trying 203.0.0.0:443...
* Connected to example.com (203.0.0.0) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384 / [blank] / UNDEF
* ALPN: server accepted h2
* Server certificate:
* subject: CN=example.com
...Si le nom commun ne correspond pas au nom d’hôte, plusieurs options sont disponibles :
- Générez et installez un certificat SSL auto-signé avec le nom commun correct, car Deflect ne nécessite pas de certificat SSL valide signé par une autorité de certification de confiance sur votre serveur d’origine.
- Demandez à Deflect de signer un certificat d’origine dans le tableau de bord sous HTTPS / TLS -> Certificats d’origine et installez-le sur votre serveur.
- Générez et installez un certificat SSL valide en utilisant Lets Encrypt ou un autre fournisseur SSL.
4.6. Correction temporaire : HTTP origin #
Attention ! Cette solution n’est pas sûre ; elle ne doit servir que de mesure temporaire jusqu’à ce qu’un correctif permanent soit mis en œuvre.
Si toutes les solutions décrites ci-dessus s’avèrent infructueuses et qu’une période de débogage est nécessaire, le problème de SNI peut être contourné en obligeant Deflect à se connecter à votre serveur d’origine via HTTP.
Pour activer le contournement, vous devez vérifier la disponibilité de HTTP sur votre serveur d’origine en vous y connectant directement via le port 80.
curl --resolve <domain name>:80:<origin server IP> "http://<domain name>"Assurez-vous que le contenu est correctement servi sur le port 80. Désactiver toute redirection 301 ou 302 vers HTTPS afin d’éviter une boucle de redirection.
Dans le tableau de bord Deflect, sous HTTPS / TLS -> HTTPS/TLS Configuration, activer le cryptage TLS flexible.
Implications en matière de sécurité: Même si votre site web reste accessible via HTTPS, la connexion sécurisée ne couvrira que le segment allant du navigateur du visiteur au Deflect edge. Les données transmises entre Deflect edge et votre serveur d’origine ne seront pas sécurisées, ce qui présente des risques potentiels.
4.7. Contacter le support Deflect #
Veuillez demander de l’aide à notre équipe d’assistance Deflect si vous avez besoin de conseils tout au long de ce processus. Incluez les messages d’erreur du serveur, les journaux d’accès et les captures d’écran pour nous aider à résoudre le problème plus rapidement.
