Je suis sûr qu'ils vérifient les capacités du client et agissent en conséquence, comme expliqué dans le fil lié à dans la réponse de @Jeff .
Pour avoir une idée à quoi cela pourrait ressembler en détail, jetez un œil à ceci . Il montre une implémentation réalisée avec HAProxypour servir différents clients différents certificats, en fonction de leurs capacités. J'ai fait un copier / coller complet, pour éviter la pourriture des liens, et parce que je pense que cette question pourrait être intéressante à l'avenir:
Les certificats SHA-1 sont sur le point de disparaître, et vous devriez passer à un certificat SHA-256 dès que possible ... sauf si vous avez de très anciens clients et devez maintenir la compatibilité SHA-1 pendant un certain temps.
Si vous êtes dans cette situation, vous devez soit forcer vos clients à effectuer une mise à niveau (difficile), soit implémenter une certaine forme de logique de sélection de certificats: nous appelons cela "commutation de certificats".
La méthode de sélection la plus déterministe consiste à servir des certificats SHA-256 aux clients qui présentent un HELLO CLIENT TLS1.2 qui annonce explicitement leur prise en charge de SHA256-RSA (0x0401) dans l'extension signature_algorithms.
Les navigateurs Web modernes enverront cette extension. Cependant, je ne connais aucun équilibreur de charge open source capable actuellement d'inspecter le contenu de l'extension signature_algorithms. Cela peut arriver dans le futur, mais pour l'instant le moyen le plus simple de réaliser la commutation de certificats est d'utiliser les ACL HAProxy SNI: si un client présente l'extension SNI, dirigez-la vers un backend qui présente un certificat SHA-256. S'il ne présente pas l'extension, supposez qu'il s'agit d'un ancien client qui parle SSLv3 ou une version cassée de TLS, et présentez-lui un certificat SHA-1.
Ceci peut être réalisé dans HAProxy en chaînant le frontend et les backends:
global
ssl-default-bind-ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128
-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-R
SA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK
frontend https-in
bind 0.0.0.0:443
mode tcp
tcp-request inspect-delay 5s
tcp-request content accept if { req_ssl_hello_type 1 }
use_backend jve_https if { req.ssl_sni -i jve.linuxwall.info }
# fallback to backward compatible sha1
default_backend jve_https_sha1
backend jve_https
mode tcp
server jve_https 127.0.0.1:1665
frontend jve_https
bind 127.0.0.1:1665 ssl no-sslv3 no-tlsv10 crt /etc/haproxy/certs/jve_sha256.pem tfo
mode http
option forwardfor
use_backend jve
backend jve_https_sha1
mode tcp
server jve_https 127.0.0.1:1667
frontend jve_https_sha1
bind 127.0.0.1:1667 ssl crt /etc/haproxy/certs/jve_sha1.pem tfo ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
mode http
option forwardfor
use_backend jve
backend jve
rspadd Strict-Transport-Security:\ max-age=15768000
server jve 172.16.0.6:80 maxconn 128
La configuration ci-dessus reçoit le trafic entrant dans le frontend appelé "https-in". Cette interface est en mode TCP et inspecte le CLIENT HELLO provenant du client pour la valeur de l'extension SNI. Si cette valeur existe et correspond à notre site cible, elle envoie la connexion au backend nommé "jve_https", qui redirige vers un frontend également nommé "jve_https" où le certificat SHA256 est configuré et servi au client.
Si le client ne parvient pas à présenter un CLIENT BONJOUR avec SNI, ou présente un SNI qui ne correspond pas à notre site cible, il est redirigé vers le backend "https_jve_sha1", puis vers son frontend correspondant où un certificat SHA1 est servi. Cette interface prend également en charge une ancienne suite de chiffrement pour accueillir les clients plus âgés.
Les deux frontends finissent par rediriger vers un seul backend nommé "jve" qui envoie du trafic vers les serveurs Web de destination.
Il s'agit d'une configuration très simple, et éventuellement elle pourrait être améliorée en utilisant de meilleures ACL (HAproxy en ajoute régulièrement des nouvelles), mais pour une configuration de base de commutation de certificats, elle fait le travail!