Tôi khá chắc chắn rằng họ đang kiểm tra các khả năng của khách hàng và hành động tương ứng, như được giải thích trong chuỗi được liên kết đến trong câu trả lời của @Jeff .
Để có được một ý tưởng làm thế nào điều này có thể trông giống như chi tiết, hãy xem cái này . Nó cho thấy một triển khai được thực hiện HAProxyđể phục vụ các khách hàng khác nhau, tùy thuộc vào khả năng của họ. Tôi đã thực hiện sao chép / dán đầy đủ, để ngăn ngừa thối liên kết và vì tôi nghĩ rằng câu hỏi này có thể được quan tâm trong tương lai:
Chứng chỉ SHA-1 đang trên đường ra và bạn nên nâng cấp lên chứng chỉ SHA-256 càng sớm càng tốt ... trừ khi bạn có khách hàng rất cũ và phải duy trì khả năng tương thích SHA-1 trong một thời gian.
Nếu bạn ở trong tình huống này, bạn cần buộc khách hàng của mình nâng cấp (khó khăn) hoặc thực hiện một số dạng logic lựa chọn chứng chỉ: chúng tôi gọi đó là "chuyển đổi chứng chỉ".
Phương pháp lựa chọn xác định nhất là cung cấp chứng chỉ SHA-256 cho các khách hàng có TLS1.2 CLIENT HELLO thông báo rõ ràng sự hỗ trợ của họ đối với SHA256-RSA (0x0401) trong tiện ích mở rộng chữ ký.
Các trình duyệt web hiện đại sẽ gửi phần mở rộng này. Tuy nhiên, tôi không biết về bất kỳ bộ cân bằng tải nguồn mở nào hiện có thể kiểm tra nội dung của phần mở rộng chữ ký. Nó có thể đến trong tương lai, nhưng bây giờ cách dễ nhất để đạt được chuyển đổi chứng chỉ là sử dụng HAProxy SNI ACLs: nếu khách hàng trình bày tiện ích mở rộng SNI, hãy chuyển hướng đến phần phụ trợ có chứng chỉ SHA-256. Nếu nó không xuất hiện tiện ích mở rộng, giả sử rằng đó là một ứng dụng khách cũ nói SSLv3 hoặc một số phiên bản bị hỏng của TLS và xuất trình chứng nhận SHA-1.
Điều này có thể đạt được trong HAProxy bằng cách xâu chuỗi frontend và backends:
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
Cấu hình ở trên nhận được lưu lượng truy cập trong giao diện được gọi là "https-in". Giao diện đó ở chế độ TCP và kiểm tra CLIENT HELLO đến từ máy khách để biết giá trị của tiện ích mở rộng SNI. Nếu giá trị đó tồn tại và phù hợp với trang đích của chúng tôi, nó sẽ gửi kết nối đến phần phụ trợ có tên "jve_https", chuyển hướng đến một frontend cũng có tên là "jve_https" nơi chứng chỉ SHA256 được cấu hình và phục vụ cho máy khách.
Nếu khách hàng không trình bày CLIENT HELLO với SNI hoặc trình bày SNI không phù hợp với trang web mục tiêu của chúng tôi, thì nó được chuyển hướng đến phụ trợ "https_jve_sha1", sau đó đến giao diện tương ứng của nó nơi chứng chỉ SHA1 được cung cấp. Frontend đó cũng hỗ trợ một ciphersuite cũ hơn để chứa các khách hàng cũ.
Cả hai frontend cuối cùng chuyển hướng đến một phụ trợ duy nhất có tên là "jve" để gửi lưu lượng truy cập đến các máy chủ web đích.
Đây là một cấu hình rất đơn giản và cuối cùng nó có thể được cải thiện bằng cách sử dụng ACL tốt hơn (HAproxy thường xuyên thêm tin tức), nhưng đối với cấu hình chuyển đổi chứng chỉ cơ bản, nó đã hoàn thành công việc!