Estoy bastante seguro de que están verificando las capacidades del cliente y actúan en consecuencia, como se explica en el hilo vinculado a la respuesta de @Jeff .
Para tener una idea de cómo esto podría ser similar en detalle, echar un vistazo a este . Muestra una implementación hecha HAProxypara servir a diferentes clientes diferentes certs, dependiendo de sus capacidades. He copiado / pegado completo, para evitar la pudrición del enlace, y porque creo que esta pregunta podría ser de interés en el futuro:
Los certificados SHA-1 están saliendo, y debe actualizar a un certificado SHA-256 lo antes posible ... a menos que tenga clientes muy antiguos y deba mantener la compatibilidad SHA-1 por un tiempo.
Si se encuentra en esta situación, debe obligar a sus clientes a actualizar (difícil) o implementar alguna forma de lógica de selección de certificados: a eso le llamamos "cambio de certificado".
El método de selección más determinista es entregar certificados SHA-256 a clientes que presentan un HOLA CLIENTE TLS1.2 que anuncia explícitamente su soporte para SHA256-RSA (0x0401) en la extensión signature_algorithms.
Los navegadores web modernos enviarán esta extensión. Sin embargo, no conozco ningún equilibrador de carga de código abierto que actualmente pueda inspeccionar el contenido de la extensión signature_algorithms. Puede venir en el futuro, pero por ahora la forma más fácil de lograr la conmutación de certificados es usar las ACL SNI de HAProxy: si un cliente presenta la extensión SNI, diríjala a un servidor que presente un certificado SHA-256. Si no presenta la extensión, suponga que es un cliente antiguo que habla SSLv3 o alguna versión dañada de TLS, y preséntele un certificado SHA-1.
Esto se puede lograr en HAProxy encadenando frontend y 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 configuración anterior recibe tráfico entrante en la interfaz llamada "https-in". Ese frontend está en modo TCP e inspecciona el CLIENTE HELLO proveniente del cliente por el valor de la extensión SNI. Si ese valor existe y coincide con nuestro sitio de destino, envía la conexión al backend llamado "jve_https", que redirige a una interfaz también llamada "jve_https" donde el certificado SHA256 se configura y sirve al cliente.
Si el cliente no puede presentar un CLIENTE HOLA con SNI, o presenta un SNI que no coincide con nuestro sitio de destino, se redirige al backend "https_jve_sha1", luego a su interfaz correspondiente donde se sirve un certificado SHA1. Esa interfaz también admite un conjunto de cifrado más antiguo para acomodar a clientes más antiguos.
Ambas interfaces eventualmente redirigen a un único backend llamado "jve" que envía tráfico a los servidores web de destino.
Esta es una configuración muy simple, y eventualmente podría mejorarse usando mejores ACL (HAproxy agrega regularmente nuevas), pero para una configuración básica de conmutación de certificados, ¡hace el trabajo!