Tenho certeza de que eles estão verificando os recursos do cliente e agem de acordo, conforme explicado no tópico vinculado na resposta de @Jeff .
Para ter uma idéia de como isso pode parecer em detalhes, dê uma olhada nisso . Ele mostra uma implementação feita HAProxypara atender diferentes clientes, diferentes certificados, dependendo de suas capacidades. Fiz uma cópia / colar completa, para evitar a podridão do link, e porque acho que essa pergunta pode ser interessante no futuro:
Os certificados SHA-1 estão saindo e você deve atualizar para um certificado SHA-256 assim que possível ... a menos que tenha clientes muito antigos e mantenha a compatibilidade com o SHA-1 por um tempo.
Se você estiver nessa situação, precisará forçar seus clientes a atualizar (difícil) ou implementar alguma forma de lógica de seleção de certificado: chamamos isso de "comutação de certificado".
O método de seleção mais determinístico é servir certificados SHA-256 para clientes que apresentam uma TLS1.2 CLIENT HELLO que anuncia explicitamente seu suporte ao SHA256-RSA (0x0401) na extensão signature_algorithms.
Navegadores modernos enviarão esta extensão. No entanto, não conheço nenhum balanceador de carga de código aberto que atualmente possa inspecionar o conteúdo da extensão signature_algorithms. Pode vir no futuro, mas, por enquanto, a maneira mais fácil de obter a troca de certificado é usar ACLs HAProxy SNI: se um cliente apresentar a extensão SNI, direcione-a para um back-end que apresente um certificado SHA-256. Se não apresentar a extensão, suponha que seja um cliente antigo que fale SSLv3 ou alguma versão quebrada do TLS e apresente um certificado SHA-1.
Isso pode ser alcançado no HAProxy, encadeando o front-end e o back-end:
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
A configuração acima recebe tráfego de entrada no front-end chamado "https-in". Esse frontend está no modo TCP e inspeciona o CLIENT HELLO vindo do cliente quanto ao valor da extensão SNI. Se esse valor existir e corresponder ao nosso site de destino, ele envia a conexão ao back-end chamado "jve_https", que redireciona para um front-end também chamado "jve_https", em que o certificado SHA256 é configurado e enviado ao cliente.
Se o cliente falhar em apresentar um CLIENT HELLO com SNI ou apresentar um SNI que não corresponda ao nosso site de destino, ele será redirecionado para o backend "https_jve_sha1" e, em seguida, para o frontend correspondente, onde um certificado SHA1 é servido. Esse front-end também suporta um ciphersuite mais antigo para acomodar clientes mais antigos.
Os dois front-end eventualmente redirecionam para um único back-end chamado "jve", que envia tráfego para os servidores da web de destino.
Essa é uma configuração muito simples e, eventualmente, pode ser aprimorada usando ACLs melhores (o HAproxy regularmente adiciona novas), mas para uma configuração básica de troca de certificado, ele faz o trabalho!