ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED trong Google Chrome

Question

Tôi có một trang web sử dụng ủy quyền chứng chỉ ứng dụng khách SSL. Tất cả chứng chỉ ứng dụng khách được tạo bằng OpenSSL và được tự ký. Mọi thứ đều hoạt động với tất cả các trình duyệt web, nhưng trình duyệt được đề xuất là Google Chrome, vì nó sử dụng cùng một kho SSL như IE, vì vậy việc cài đặt chứng chỉ khá dễ dàng (nhấp chuột-mật khẩu xong!). Sau lần cập nhật cuối cùng của Google "Chrome 29.0.1547.57 m", không ai có thể truy cập máy chủ web của tôi, kể cả tôi. Chỉ lỗi Google chrome! IE và FF hoạt động tốt. Lỗi là: ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED. Tương tự trong nhật ký lỗi máy chủ. Bạn có đề xuất nào không? Vấn đề là phần lớn khách hàng không quen thuộc với PC và họ rất sợ hãi về tình huống đó. Vì vậy, điện thoại hỗ trợ kẻ đang dưới làn sóng của các cuộc gọi.

Answer 1

Tôi đang gặp điều tương tự ở đây với các hệ thống máy khách Windows7 không thể xác thực bằng chứng chỉ ứng dụng đối với một số hệ thống của chúng tôi, chứ không phải các hệ thống khác. Các máy chủ bị ảnh hưởng đang chạy Apache Tomcat trong khi không bị ảnh hưởng đang chạy IIS7, mặc dù tôi do dự để xác định sự khác biệt đó là thủ phạm.

Còn ai khác nhìn thấy điều này không?

EDIT:

Tôi có thể loại bỏ các vấn đề bằng cách tắt TLSv1.2 trên máy chủ. Có ai khác có thể tái tạo trải nghiệm này không?

Tôi cũng muốn biết liệu có ai khác đang xem nội dung này trên nền tảng Windows hay không vì đây là nơi duy nhất xảy ra ở đây (cùng một phiên bản OSX không có vấn đề gì).

EDIT2:

Chrome Báo cáo Lỗi ở đây: https://code.google.com/p/chromium/issues/detail?id=278370

EDIT3:

nên được làm việc một lần nữa trong ổn định Chrome mới nhất. Chrome 30 sẽ có bản sửa lỗi mạnh mẽ hơn, nhưng 29.x cũng sẽ hoạt động ngay bây giờ.

Answer 2

Kết hợp Win XP và Google Chrome 29.0.1547.57 m Ngày Win 7/8 sự cố này không xảy ra.

Bạn có thể cài đặt phiên bản làm việc cũ 28.0.1500.95 http://www.filehippo.com/download_google_chrome/15657/

Nhưng cài đặt cho việc vô hiệu hóa cập nhật không phải là dễ dàng như vậy. http://dev.chromium.org/administrators/turning-off-auto-updates

Answer 3

Chúng tôi đang gặp sự cố tương tự. Như Sean đã báo cáo, có vẻ như Chrome trên Windows XP thương lượng TLSv1.2 mặc dù hệ điều hành không hỗ trợ hàm băm SHA-2 (nói, SHA-256 hoặc SHA-384) .

Chúng tôi nhận thấy Chrome không thành công khi nhận được "yêu cầu chứng chỉ ứng dụng khách" sau SERVER HELLO. SERVER HELLO tự đàm phán RC4-SHA1 (trong môi trường của chúng tôi) sẽ thành công. Gói có vấn đề dường như là "yêu cầu chứng chỉ ứng dụng khách" bao gồm các hàm SHA-2 (cũng như SHA1) cho các băm.

Gọi Chrome với "enable-logging --log-level = 0" kết quả đầu ra được thông báo sau: LỖI: nss_ssl_util.cc (193)] ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED: NSS lỗi -12.222, lỗi hệ điều hành -2146893816

Đây là lỗi Hệ điều hành tương ứng với "NTE_BAD_ALGID" cho hàm CryptSignHash: http://msdn.microsoft.com/en-us/library/windows/desktop/aa380280(v=vs.85).aspx

Tắt TLSv1.2 trên máy chủ sẽ khắc phục sự cố. Nhưng tôi nghĩ Chrome nên thích SHA1 trên Windows XP hơn.

Answer 4

Sự cố là do Chrome đang chạy TLSv1.2 trên Windows XP.

Điều này có thể bị vô hiệu hóa ở phía máy chủ mà còn ở phía máy khách.

Để chạy Chrome với một phiên bản thấp hơn của TLS, hãy bắt đầu nó với các tùy chọn dòng lệnh --ssl phiên bản-max = tls1.1

Answer 5

Tôi có vấn đề này Connecting Chrome với WebSockets để proxy_wstunnel_module ném apache.

Giải pháp của tôi đã được cấu hình httpd.conf

ProxyPass /wss2/ ws://127.0.0.1:8080/ retry=0 keepalive=On 
ProxyPassReverse /wss2/ ws://127.0.0.1:8080/ retry=0 
    <Location /wss2/> 
     SSLRequireSSL On 
     SSLVerifyClient none 
     SSLVerifyDepth 1 
     SSLOptions +StdEnvVars +StrictRequire 
     SSLRenegBufferSize 10486000 
    </Location> 

Chrome WebSockets không thích tham số tùy chọn SSLVerifyClient

Tôi hy vọng điều này sẽ giúp.