Sono abbastanza sicuro che stiano verificando le capacità del client e agiscano di conseguenza, come spiegato nel thread collegato nella risposta di @Jeff .
Per avere un'idea di come potrebbe apparire nei dettagli, dai un'occhiata a questo . Mostra un'implementazione realizzata HAProxyper servire diversi clienti diversi certificati, a seconda delle loro capacità. Ho fatto una copia / incolla completa, per prevenire la putrefazione dei link e perché penso che questa domanda potrebbe essere di interesse per il futuro:
I certificati SHA-1 stanno per uscire e dovresti passare a un certificato SHA-256 il prima possibile ... a meno che tu non abbia client molto vecchi e debba mantenere la compatibilità SHA-1 per un po '.
Se ti trovi in questa situazione, devi forzare i tuoi clienti a eseguire l'aggiornamento (difficile) o implementare una qualche forma di logica di selezione dei certificati: la chiamiamo "cert switching".
Il metodo di selezione più deterministico consiste nel fornire certificati SHA-256 ai client che presentano un CLIENT CIAO TLS1.2 che annuncia esplicitamente il loro supporto per SHA256-RSA (0x0401) nell'estensione signature_algorithms.
I browser Web moderni invieranno questa estensione. Tuttavia, non sono a conoscenza di alcun servizio di bilanciamento del carico open source attualmente in grado di ispezionare il contenuto dell'estensione signature_algorithms. Potrebbe venire in futuro, ma per ora il modo più semplice per ottenere il cambio di certificato è usare ACL SNAP HAProxy: se un client presenta l'estensione SNI, indirizzalo a un back-end che presenta un certificato SHA-256. Se non presenta l'estensione, supponi che sia un vecchio client che parla SSLv3 o una versione non funzionante di TLS e presenta un certificato SHA-1.
Ciò può essere ottenuto in HAProxy concatenando frontend e backend:
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 configurazione sopra riceve traffico in entrata nel frontend chiamato "https-in". Quel frontend è in modalità TCP e controlla il CLIENT HELLO proveniente dal client per il valore dell'estensione SNI. Se quel valore esiste e corrisponde al nostro sito di destinazione, invia la connessione al back-end denominato "jve_https", che reindirizza a un front-end chiamato anche "jve_https" in cui il certificato SHA256 è configurato e servito al client.
Se il client non riesce a presentare un CLIENT HELLO con SNI o presenta un SNI che non corrisponde al nostro sito di destinazione, viene reindirizzato al backend "https_jve_sha1", quindi al frontend corrispondente dove viene offerto un certificato SHA1. Quel frontend supporta anche una suite di cifratura precedente per soddisfare i client più vecchi.
Entrambi i frontend alla fine reindirizzano a un singolo backend chiamato "jve" che invia il traffico ai server Web di destinazione.
Questa è una configurazione molto semplice, e alla fine potrebbe essere migliorata usando ACL migliori (HAproxy ne aggiunge regolarmente di nuovi), ma per una configurazione di commutazione di cert di base, fa il lavoro!