同时运行下面的命令openssl s_client -host example.xyz -port 9093
我得到以下错误。
139810559764296:error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate:s3_pkt.c:1259:SSL alert number 42 39810559764296:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:184: 但最后我得到"Verify return code: 0 (ok)"消息。
我的问题是上面的警报是什么意思，如果SSL实际上是成功的。 预先感谢您的帮助。
SSL handshake has read 6648 bytes and written 354 bytes New, TLSv1/SSLv3, Cipher is AES128-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : AES128-SHA Session-ID: xx Session-ID-ctx: Master-Key: xx Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None Start Time: 1475096098 Timeout : 300 (sec) **Verify return code: 0 (ok)**
“握手失败”表示握手失败，并且没有SSL / TLS连接。 您应该看到openssl退出到shell（或CMD等），不等待input数据发送到服务器。 “validation返回代码0”意味着在服务器的证书中没有发现问题，或者是因为它没有被检查，或者是因为它被检查并且是好的（就OpenSSL的检查而言，这并不包括所有内容）。 在这种情况下，通过了解协议，我们可以推断出后一种情况适用。
接收警报bad certificate （代码42） 意味着服务器要求您使用证书进行身份validation ，而您没有这样做，导致握手失败。 在SSL handshake has read ... and written ...行SSL handshake has read ... and written ...之前的几行内容，您应该看到一行Acceptable client certificate CA names通常后面跟着几行标识CA的行，可能后面跟着一行起始Client Certificate Types ，可能还有一些关于Requested Signature Algorithms取决于您的OpenSSL版本和协商的协议。
在“可接受”列表中查找由CA颁发的证书 ，或者如果它是空的，则查找关于服务器或关于服务器的文档，以说明它信任的CA或与服务器操作员或所有者联系并询问他们， 以及匹配的私钥以PEM格式， 并用-cert $file -key $file 指定它们 ; 如果您同时拥有一个文件，那么可以使用-cert $file 。 如果你有不同的格式，可以指定它，或者在这里search，也许是超级用户和security.SX; 关于转换各种证书和私钥格式已经有很多问题了。 如果您的证书需要“连锁”或“中级”证书（或甚至多于一个）进行validation，而公共CA（而不是内部证书）的证书经常是这种情况，这取决于服务器的configuration方式， s_client需要一个技巧：或者将链式证书添加到系统信任库中，或者创build一个包含CA证书的本地/临时信任库，以validation服务器加上您需要发送的链式证书。
如果你没有这样的证书，你需要得到一个，这是一个不同的问题，需要更多的细节来回答，或者你需要find一种方法来连接到服务器，而不使用证书authentication; 再次检查文件和/或询问经营者/业主。
编辑：从评论你可能有客户端密钥和证书链，以及在Java服务器锚（s？）。 在检查时，我没有看到一个完全覆盖这个案例的好的现有答案，所以即使这可能不会很好地search：
# 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