"Lỗi bắt tay" có nghĩa là bắt tay không thành công và không có kết nối SSL / TLS. Bạn sẽ thấy openssl
lối thoát đó vào shell (hoặc CMD, v.v.) và không chờ dữ liệu đầu vào được gửi đến máy chủ. "Xác minh mã trả về 0" có nghĩa là không có vấn đề nào được tìm thấy trong chứng chỉ của máy chủ, vì nó hoàn toàn không được kiểm tra hoặc vì nó đã được kiểm tra và tốt (theo như kiểm tra của OpenSSL, không bao gồm mọi thứ); trong trường hợp này bằng cách biết giao thức, chúng ta có thể suy ra trường hợp sau được áp dụng.
Nhận thông báobad certificate
(mã 42) có nghĩa là máy chủ yêu cầu bạn xác thực bằng chứng chỉ và bạn đã không làm như vậy và điều đó gây ra lỗi bắt tay. Một vài dòng trước dòng SSL handshake has read ... and written ...
bạn sẽ thấy một dòng Acceptable client certificate CA names
thường được theo sau bởi một vài dòng xác định CA, có thể theo sau là một dòng bắt đầu Client Certificate Types
và có thể một số Requested Signature Algorithms
tùy thuộc vào phiên bản OpenSSL của bạn và giao thức được đàm phán.
Tìm chứng chỉ do CA cấp trong danh sách 'chấp nhận được' hoặc nếu nó trống tìm tài liệu trên hoặc về máy chủ cho biết CA nào tin tưởng hoặc liên hệ với nhà điều hành máy chủ hoặc chủ sở hữu và hỏi họ, cộng với khóa riêng phù hợp , cả hai trong định dạng PEM và chỉ định chúng với -cert $file -key $file
; nếu bạn có cả hai trong một tệp, như có thể với PEM, chỉ cần sử dụng-cert $file
. Nếu bạn có chúng ở một định dạng khác, hãy chỉ định nó hoặc tìm kiếm ở đây và có lẽ là siêu người dùng và bảo mật.SX; đã có nhiều câu hỏi và trả lời về việc chuyển đổi các định dạng chứng chỉ và privatekey khác nhau. Nếu chứng chỉ của bạn cần một chứng chỉ "chuỗi" hoặc "trung gian" (hoặc thậm chí nhiều hơn một) để được xác minh, như trường hợp chứng chỉ từ một CA công cộng (so với một kênh) tùy thuộc vào cách máy chủ được cấu hình, s_client
yêu cầu một mẹo: thêm chứng chỉ chuỗi vào kho ủy thác hệ thống của bạn hoặc tạo kho ủy thác cục bộ / tạm thời có chứa chứng chỉ CA mà bạn cần để xác minh máy chủ PLUS (các) chứng chỉ chuỗi bạn cần gửi.
Nếu bạn không có chứng chỉ như vậy, bạn cần phải có một chứng chỉ, đó là một câu hỏi khác đòi hỏi nhiều chi tiết hơn để trả lời hoặc bạn cần tìm cách kết nối với máy chủ mà không cần sử dụng xác thực chứng chỉ; kiểm tra lại tài liệu và / hoặc hỏi người vận hành / chủ sở hữu.
EDIT: Nó xuất hiện từ bình luận, bạn có thể có khóa máy khách và chuỗi chứng chỉ cũng như (các?) Máy chủ neo trong Java. Khi kiểm tra tôi không thấy một câu trả lời tốt hiện có bao gồm đầy đủ trường hợp đó, vì vậy mặc dù điều này có lẽ sẽ không tìm kiếm tốt:
# Assume Java keystore is type JKS (the default but not only possibility)
# named key.jks and the privatekey entry is named mykey (ditto)
# and the verify certs are in trust.jks in entries named trust1 trust2 etc.
# convert Java key entry to PKCS12 then PKCS12 to PEM files
keytool -importkeystore -srckeystore key.jks -destkeystore key.p12 -deststoretype pkcs12 -srcalias mykey
openssl pkcs12 -in key.p12 -nocerts -out key.pem
openssl pkcs12 -in key.p12 -nokeys -clcerts -out cert.pem
openssl pkcs12 -in key.p12 -nokeys -cacerts -out chain.pem
# extract verify certs to individual PEM files
# (or if you 'uploaded' PEM files and still have them just use those)
keytool -keystore trust.jks -export -alias trust1 -rfc -file trust1.pem
keytool -keystore trust.jks -export -alias trust2 -rfc -file trust2.pem
... more if needed ...
# combine for s_client
cat chain.pem trust*.pem >combined.pem
openssl s_client -connect host:port -key key.pem -cert cert.pem -CAfile combined.pem