Jestem pewien, że sprawdzają możliwości klienta i działają odpowiednio, jak wyjaśniono w wątku powiązanym z odpowiedzią @Jeff .
Aby dowiedzieć się, jak to szczegółowo może wyglądać, spójrz na to . Pokazuje implementację wykonaną w HAProxycelu obsługi różnych klientów różnych certyfikatów, w zależności od ich możliwości. Zrobiłem pełną kopię / wklej, aby zapobiec gniciu linków, a ponieważ uważam, że to pytanie może być interesujące w przyszłości:
Certyfikaty SHA-1 są w drodze do wyjścia i należy jak najszybciej uaktualnić do certyfikatu SHA-256 ... chyba że masz bardzo starych klientów i musisz zachować zgodność z SHA-1 przez jakiś czas.
Jeśli jesteś w takiej sytuacji, musisz albo zmusić swoich klientów do uaktualnienia (trudne) lub zaimplementować logikę wyboru certyfikatu: nazywamy to „przełączaniem certyfikatu”.
Najbardziej deterministyczną metodą selekcji jest obsługa certyfikatów SHA-256 klientom, którzy prezentują WITAMI KLIENTÓW TLS1.2, którzy jawnie ogłaszają wsparcie dla SHA256-RSA (0x0401) w rozszerzeniu algorytm podpisu.
Nowoczesne przeglądarki internetowe wyślą to rozszerzenie. Jednak nie znam żadnego modułu równoważenia obciążenia typu open source, który obecnie jest w stanie sprawdzić zawartość rozszerzenia podpis_algorytmy. Może przyjść w przyszłości, ale na razie najłatwiejszym sposobem na przełączenie certyfikatu jest użycie list ACL HAProxy SNI: jeśli klient przedstawia rozszerzenie SNI, skieruj go do backendu, który przedstawia certyfikat SHA-256. Jeśli nie przedstawia rozszerzenia, załóż, że jest to stary klient, który mówi SSLv3 lub jakąś zepsutą wersję TLS, i przedstaw mu certyfikat SHA-1.
Można to osiągnąć w HAProxy, łącząc frontend i backendy:
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
Powyższa konfiguracja odbiera ruch przychodzący w interfejsie o nazwie „https-in”. Ten interfejs jest w trybie TCP i sprawdza, czy CLIENT HELLO pochodzi od klienta pod kątem wartości rozszerzenia SNI. Jeśli ta wartość istnieje i jest zgodna z naszą witryną docelową, wysyła połączenie do zaplecza o nazwie „jve_https”, który przekierowuje do interfejsu o nazwie również „jve_https”, w którym certyfikat SHA256 jest skonfigurowany i podawany klientowi.
Jeśli klient nie zaprezentuje WITA KLIENTA z SNI lub przedstawi SNI, który nie pasuje do naszej strony docelowej, zostanie przekierowany do backendu „https_jve_sha1”, a następnie do odpowiedniego interfejsu, na którym jest obsługiwany certyfikat SHA1. Ten interfejs obsługuje również starszą wersję szyfrowania, aby pomieścić starszych klientów.
Oba interfejsy ostatecznie przekierowują do jednego backendu o nazwie „jve”, który wysyła ruch do docelowych serwerów WWW.
Jest to bardzo prosta konfiguracja, która ostatecznie może zostać ulepszona za pomocą lepszych list ACL (HAproxy regularnie dodaje wiadomości), ale w przypadku podstawowej konfiguracji przełączania certyfikatów zadanie to się robi!