Tous les produits
Search

Ce produit

    :Problèmes d'accès HTTPS causés par le SNI

    Centre de documentation

    :Problèmes d'accès HTTPS causés par le SNI

    Dernière mise à jour :Aug 11, 2026

    Qu'est-ce que le SNI ?

    Les hôtes virtuels permettent à plusieurs noms de domaine de partager une seule adresse IP, ce qui contribue à pallier la pénurie d'adresses IPv4. Un serveur achemine les requêtes vers différents noms de domaine (hôtes virtuels) en fonction du champ host présent dans la requête du client.

    Cette approche pose problème pour les serveurs HTTPS qui hébergent plusieurs noms de domaine sur une unique adresse IP. Avant la fin de la négociation TLS, le serveur ignore le nom de domaine demandé par le client et ne peut pas présenter le certificat approprié pour l'hôte virtuel cible.

    Le Server Name Indication (SNI) résout ce problème en exigeant que le client indique le nom de domaine cible durant la négociation TLS. Le serveur sélectionne alors le certificat adéquat pour finaliser la négociation et établir une connexion TLS.

    Proposé pour la première fois en 2004, le SNI est pris en charge par la plupart des navigateurs, serveurs et outils de test modernes.

    Pourquoi Anti-DDoS Proxy et Web Application Firewall exigent-ils la prise en charge du SNI par les clients ?

    Anti-DDoS Proxy et Web Application Firewall (WAF) agissent comme des proxys inverses pour les services HTTPS. Vous devez importer un certificat et sa clé privée lors de la configuration de la protection HTTPS. Étant donné que le nombre d'adresses IP d'Anti-DDoS Proxy et de serveurs WAF est limité, les clusters de services hébergent plusieurs noms de domaine sur les mêmes serveurs. Par conséquent, les clients doivent prendre en charge le SNI pour interagir correctement avec Anti-DDoS Proxy et WAF.

    Si un navigateur incompatible avec le SNI accède à un site web protégé par Anti-DDoS Proxy ou WAF, le service ne peut pas identifier le nom de domaine demandé. Il utilise alors un certificat par défaut intégré, ce qui entraîne l'affichage d'un avertissement « server certificate not trusted » dans le navigateur.

    Remarque

    Même si le serveur réel ne possède qu'un seul nom de domaine et ne partage pas son adresse IP, le client doit toujours prendre en charge le SNI, car Anti-DDoS Proxy ou WAF agit en tant que proxy inverse. Le client doit d'abord établir une connexion avec Anti-DDoS Proxy ou WAF.

    Solutions

    Server-side

    Configurez votre serveur pour qu'il prenne en charge le SNI.

    Client-side

    Si vos clients ne prennent pas en charge le SNI, appliquez l'une des solutions suivantes :

    • Invitez les utilisateurs à adopter un navigateur moderne, tel que Google Chrome ou Firefox.

    • Ne configurez pas la protection de site web de couche 7 dans le service Anti-DDoS Proxy. Optez plutôt pour une protection de site web via la redirection de port de couche 4.

      Remarque

      La protection des ports de couche 4 ne protège pas contre les attaques CC.

    SNI compatibility

    Remarque

    Le SNI est compatible avec TLS 1.1 et versions ultérieures, mais il ne l'est pas avec le protocole SSL.

    • Navigateurs de bureau pris en charge :

      • Chrome 5 et versions ultérieures

      • Chrome 6 et versions ultérieures

      • Firefox 2 et versions ultérieures

      • Internet Explorer 7 et versions ultérieures (uniquement sur Windows Vista, Windows Server 2008 et systèmes d'exploitation ultérieurs. Aucune version d'Internet Explorer sous Windows XP ne prend en charge le SNI.)

      • Konqueror 4.7 et versions ultérieures

      • Opera 8 et versions ultérieures

      • Safari 3.0 et versions ultérieures (uniquement sur Windows Vista, Windows Server 2008 et versions ultérieures, ou sur Mac OS X 10.5.6 et versions ultérieures.)

    • Navigateurs mobiles pris en charge :

      • Android 3.0 Honeycomb et versions ultérieures

      • iOS 4 et versions ultérieures

      • Windows Phone 7 et versions ultérieures

    • Serveurs pris en charge :

      • Apache 2.2.12 et versions ultérieures

      • Apache Traffic Server 3.2.0 et versions ultérieures

      • Cherokee

      • HAProxy 1.5 et versions ultérieures

      • IIS 8.0 et versions ultérieures

      • Lighttpd 1.4.24 et versions ultérieures

      • LiteSpeed 4.1 et versions ultérieures

      • Nginx 0.5.32 et versions ultérieures

    • Outils en ligne de commande pris en charge :

      • cURL 7.18.1 et versions ultérieures

      • wget 1.14 et versions ultérieures

    • Bibliothèques prises en charge :

      • GNU TLS

      • JSSE (Oracle Java) 7 et versions ultérieures (en tant que client uniquement)

      • libcurl 7.18.1 et versions ultérieures

      • NSS 3.1.1 et versions ultérieures

      • OpenSSL 0.9.8j et versions ultérieures

      • OpenSSL 0.9.8f et versions ultérieures (nécessite une configuration via des indicateurs)

      • Qt 4.8 et versions ultérieures