@Jeff의 답변에 링크 된 스레드에 설명 된 것처럼 클라이언트 기능을 확인하고 그에 따라 행동한다고 ​​확신합니다 .

이 자세히과 같이 수 있는지 아이디어를 얻으려면 모습이 이것을 . HAProxy기능에 따라 서로 다른 클라이언트에게 서로 다른 인증서를 제공하기 위해 만들어진 구현을 보여줍니다 . 링크 썩음을 방지하기 위해 전체 복사 / 붙여 넣기를 수행 했으며이 질문이 미래에 관심이있을 수 있다고 생각합니다.

SHA-1 인증서가 곧 나옵니다. 아주 오래된 클라이언트가없고 잠시 동안 SHA-1 호환성을 유지해야하는 경우가 아니면 가능한 한 빨리 SHA-256 인증서로 업그레이드해야합니다.

이러한 상황에 처한 경우 고객이 클라이언트를 강제로 업그레이드 (어려워)하거나 일종의 인증서 선택 논리를 구현해야합니다.이를 “인증서 전환”이라고합니다.

가장 결정적인 선택 방법은 signature_algorithms 확장에서 SHA256-RSA (0x0401)에 대한 지원을 명시 적으로 알리는 TLS1.2 CLIENT HELLO를 제공하는 클라이언트에 SHA-256 인증서를 제공하는 것입니다.

최신 웹 브라우저는이 확장을 보냅니다. 그러나 현재 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”라는 백엔드로 연결을 전송합니다.이 연결은 SHA256 인증서가 구성되어 클라이언트에 제공되는 “jve_https”라는 프런트 엔드로 리디렉션됩니다.

클라이언트가 SNI를 사용하여 CLIENT HELLO를 제시하지 않거나 대상 사이트와 일치하지 않는 SNI를 제시하면 “https_jve_sha1″백엔드로 경로 재 지정된 후 SHA1 인증서가 제공되는 해당 프론트 엔드로 경로 재 지정됩니다. 이 프론트 엔드는 또한 이전 클라이언트를 수용하기 위해 이전 암호 스위트를 지원합니다.

두 프런트 엔드는 결국 “jve”라는 단일 백엔드로 리디렉션되어 트래픽을 대상 웹 서버로 보냅니다.

이것은 매우 간단한 구성이며 결국 더 나은 ACL (HAproxy가 정기적으로 뉴스를 추가 함)을 사용하여 개선 할 수 있지만 기본 인증서 전환 구성의 경우 작업이 완료됩니다!

답변