Я вполне уверен, что они проверяют возможности клиента и действуют соответственно, как объяснено в теме, связанной с ответом @Jeff .
Чтобы понять, как это может выглядеть в деталях, взгляните на это . Он показывает реализацию, сделанную HAProxyдля обслуживания разных клиентов разными сертификатами, в зависимости от их возможностей. Я сделал полное копирование / вставку, чтобы предотвратить гниение ссылок, и потому что я думаю, что этот вопрос может быть интересен в будущем:
Сертификаты SHA-1 находятся на выходе, и вам следует как можно скорее перейти на сертификат SHA-256 ... если у вас нет очень старых клиентов и вы должны некоторое время поддерживать совместимость с SHA-1.
Если вы находитесь в такой ситуации, вам нужно либо принудить своих клиентов обновить (сложно), либо внедрить некоторую логику выбора сертификата: мы называем это «переключение сертификатов».
Наиболее детерминированный метод выбора заключается в предоставлении сертификатов SHA-256 клиентам, которые представляют ПРИВЕТ КЛИЕНТА TLS1.2, который явно объявляет о своей поддержке SHA256-RSA (0x0401) в расширении signature_algorithms.
Современные веб-браузеры отправят это расширение. Однако я не знаю ни о каком распределителе нагрузки с открытым исходным кодом, который в настоящее время может проверять содержимое расширения signature_algorithms. Это может произойти в будущем, но на данный момент самый простой способ добиться сертификата переключения - это использовать ACL SNAP HAProxy: если клиент представляет расширение SNI, направьте его в бэкэнд, который представляет сертификат SHA-256. Если он не представляет расширение, предположим, что это старый клиент, использующий SSLv3 или неработающую версию TLS, и предоставьте ему сертификат SHA-1.
Это может быть достигнуто в HAProxy путем объединения внешнего интерфейса и внутреннего интерфейса:
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
Приведенная выше конфигурация получает входящий трафик в интерфейсе, называемом «https-in». Этот интерфейс находится в режиме TCP и проверяет КЛИЕНТ ПРИВЕТ, исходящий от клиента, для определения значения расширения SNI. Если это значение существует и соответствует нашему целевому сайту, оно отправляет соединение на сервер с именем «jve_https», который перенаправляет на внешний интерфейс, также называемый «jve_https», где сертификат SHA256 настроен и передан клиенту.
Если клиенту не удается представить CLIENT HELLO с SNI или представить SNI, который не соответствует нашему целевому сайту, он перенаправляется на бэкэнд «https_jve_sha1», а затем на соответствующий ему интерфейс, где обслуживается сертификат SHA1. Этот интерфейс также поддерживает более старый набор шифров для поддержки старых клиентов.
Оба интерфейса в конечном итоге перенаправляют на один сервер с именем «jve», который отправляет трафик на веб-серверы назначения.
Это очень простая конфигурация, и в конечном итоге ее можно улучшить, используя лучшие списки ACL (HAproxy регулярно добавляет новостные), но для базовой конфигурации переключения сертификатов она выполняет свою работу!