Я впевнений, що вони перевіряють можливості клієнта і діють відповідно, як це пояснено в потоці, пов'язаному з відповіддю @Jeff .
Щоб зрозуміти, як це може виглядати детально, погляньте на це . Він показує реалізацію, виконану HAProxyдля обслуговування різних клієнтів різних сертів, залежно від їх можливостей. Я зробив повну копію / вставлення, щоб запобігти гниттю посилань, і тому, думаю, це питання може зацікавити в майбутньому:
Сертифікати SHA-1 вже виходять, і вам слід якнайшвидше оновити сертифікат до SHA-256 ... якщо ви не маєте дуже старих клієнтів і повинні підтримувати сумісність SHA-1 деякий час.
Якщо ви опинилися в цій ситуації, вам потрібно або змусити своїх клієнтів оновити (важко) або реалізувати певну форму логіки вибору сертифікатів: ми називаємо це "переключенням cert".
Найбільш детермінований метод вибору - це обслуговування сертифікатів SHA-256 клієнтам, які представляють TLS1.2 CLIENT HELLO, який явно оголошує про підтримку SHA256-RSA (0x0401) у розширенні підпису_алгоритмів.
Сучасні веб-браузери надсилають це розширення. Однак я не знаю жодного балансира навантаження з відкритим кодом, який наразі може перевірити вміст розширення підпис_алгоритми. Це може виникнути в майбутньому, але наразі найпростішим способом домогтися перемикання cert є використання ACL-файлів HAProxy SNI: якщо клієнт представляє розширення SNI, направляйте його на бекенд, який представляє сертифікат SHA-256. Якщо в ньому немає розширення, припустімо, що це старий клієнт, який розмовляє SSLv3 або якась зламана версія TLS, і представіть йому cert 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 і перевіряє КЛІЄНТУ HELLO, що надходить від клієнта, на значення розширення SNI. Якщо це значення існує і відповідає нашому цільовому сайту, воно посилає підключення до бекенда з назвою "jve_https", який перенаправляє на фронтенд, також названий "jve_https", де налаштований сертифікат SHA256 і подається клієнту.
Якщо клієнт не представляє КЛІЄНТУ HELLO з SNI або представляє SNI, який не відповідає нашому цільовому сайту, його переспрямовують на "https_jve_sha1" бекенд, а потім на відповідний інтерфейс, де подається сертифікат SHA1. Цей інтерфейс також підтримує старший шифрсуїт для розміщення старших клієнтів.
Обидва фронтени врешті-решт переспрямовуються на єдиний бекенд з назвою "jve", який направляє трафік на веб-сервери призначення.
Це дуже проста конфігурація, і в кінцевому підсумку її можна вдосконалити за допомогою кращих ACL (HAproxy регулярно додає новини), але для базової конфігурації перемикання cert це виконує завдання!