Как работает переключение сертификатов HTTPS (как на suche.org)?

Я совершенно уверен, что они проверяют возможности клиента и действуют соответственно, как описано в теме, связанной с в ответ @Jeff.

Чтобы получить представление о том, как это может выглядеть в деталях, посмотрите в этот. Он показывает реализацию, выполненную с HAProxy обслуживать разных клиентов разные сертификаты в зависимости от их возможностей. Я сделал полное копирование / вставку, чтобы предотвратить гниение ссылок, и потому что я думаю, что этот вопрос может быть интересен в будущем:

Сертификаты SHA-1 находятся в процессе выхода, и вам следует как можно скорее перейти на сертификат SHA-256 ... если только у вас нет очень старых клиентов и вам необходимо некоторое время поддерживать совместимость с SHA-1.

Если вы находитесь в такой ситуации, вам нужно либо заставить своих клиентов обновиться (сложно), либо реализовать некоторую форму логики выбора сертификата: мы называем это «переключением сертификатов».

Наиболее детерминированный метод выбора заключается в предоставлении сертификатов SHA-256 клиентам, которые представляют TLS1.2 CLIENT HELLO, который явно объявляет о своей поддержке SHA256-RSA (0x0401) в расширении signature_algorithms.

Современные веб-браузеры отправляют это расширение. Однако мне неизвестен какой-либо балансировщик нагрузки с открытым исходным кодом, который в настоящее время может проверять содержимое расширения signature_algorithms. Это может произойти в будущем, но на данный момент самый простой способ добиться переключения сертификатов - использовать HAProxy SNI ACL: если клиент представляет расширение 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 и проверяет CLIENT HELLO, исходящий от клиента, на предмет значения расширения SNI. Если это значение существует и соответствует нашему целевому сайту, оно отправляет соединение с серверной частью с именем «jve_https», которая перенаправляет на интерфейс, также называемый «jve_https», где сертификат SHA256 настроен и обслуживается клиентом.

Если клиент не может представить КЛИЕНТСКОЕ ПРИВЕТСТВИЕ с SNI или представляет SNI, который не соответствует нашему целевому сайту, он перенаправляется на бэкэнд «https_jve_sha1», а затем в соответствующий интерфейс, где обслуживается сертификат SHA1. Этот интерфейс также поддерживает старый набор шифров для работы со старыми клиентами.

Оба интерфейса в конечном итоге перенаправляют на один сервер с именем «jve», который отправляет трафик на целевые веб-серверы.

Это очень простая конфигурация, и в конечном итоге ее можно улучшить, используя более качественные ACL (HAproxy регулярно добавляет новостные), но для базовой конфигурации переключения сертификатов он выполняет свою работу!

Аналогичный вопрос был задан на https://community.qualys.com/thread/16387

думаю этот Ответ - это решение:

suche.org - умная реализация. Насколько я понимаю, он запрашивает возможности клиента, а затем предлагает только лучшее из имеющихся, чтобы устранить любые сомнения.