Java的SSL握手失败 - 没有客户端证书
问题描述:
我在SSL客户端使用第三方库,构建执行对PKCS#7签名CRL检查。Java的SSL握手失败 - 没有客户端证书
我创建了一个密钥库和信任,并把服务器的CA在我的信任。
展望下面的调试,该证书颁发机构和证书链都是空的。我的客户没有寄回他的证书。
你能解释一下它发生了什么吗?
编辑
由于下面的评论,我理解,客户端的“空CA”是没有问题的。
的问题是,服务器请求客户端证书,但我的客户不将其发送到服务器。
为什么客户端不发送他的证书?
keyStore is : [...]
keyStore type is : jks
keyStore provider is :
init keystore
init keymanager of type SunX509
***
found key for : [...]
chain [0] = [
...
]
***
trustStore is: [...]
trustStore type is : jks
trustStore provider is :
init truststore
adding as trusted cert:
[...]
trigger seeding of SecureRandom
done seeding SecureRandom
Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
[...]
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA256
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
main, setSoTimeout(10000) called
%% No cached client session
*** ClientHello, TLSv1
RandomCookie: GMT: 1445266954 bytes = { 44, 84, 229, 125, 84, 33, 145, 120, 170, 228, 77, 65, 146, 200, 227, 227, 48, 200, 116, 240, 140, 55, 227, 162, 119, 75, 116, 47 }
Session ID: {}
Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_MD5, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods: { 0 }
Extension elliptic_curves, curve names: {secp256r1, sect163k1, sect163r2, secp192r1, secp224r1, sect233k1, sect233r1, sect283k1, sect283r1, secp384r1, sect409k1, sect409r1, secp521r1, sect571k1, sect571r1, secp160k1, secp160r1, secp160r2, sect163r1, secp192k1, sect193r1, sect193r2, secp224k1, sect239k1, secp256k1}
Extension ec_point_formats, formats: [uncompressed]
Extension server_name, server_name: [host_name: ...]
***
[write] MD5 and SHA1 hashes: len = 176
[...]
main, WRITE: TLSv1 Handshake, length = 176
[Raw write]: length = 181
[...]
[Raw read]: length = 5
[...]
[Raw read]: length = 85
[...]
main, READ: TLSv1 Handshake, length = 85
*** ServerHello, TLSv1
RandomCookie: GMT: 1929314415 bytes = { 133, 174, 213, 209, 239, 104, 185, 151, 182, 150, 87, 234, 171, 201, 244, 45, 171, 118, 159, 20, 148, 138, 19, 5, 1, 44, 188, 76 }
Session ID: {144, 227, 198, 123, 46, 241, 49, 85, 156, 181, 102, 130, 42, 23, 39, 17, 11, 64, 23, 39, 166, 11, 119, 139, 12, 51, 60, 252, 170, 105, 23, 161}
Cipher Suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: <empty>
Extension server_name, server_name:
***
%% Initialized: [Session-1, SSL_RSA_WITH_3DES_EDE_CBC_SHA]
** SSL_RSA_WITH_3DES_EDE_CBC_SHA
[read] MD5 and SHA1 hashes: len = 85
[...]
[Raw read]: length = 5
[...]
[Raw read]: length = 1024
[...]
main, READ: TLSv1 Handshake, length = 1024
*** Certificate chain
chain [0] = [
[
[...]
]
Algorithm: [SHA1withRSA]
Signature:
[...]
]
***
Found trusted certificate:
[
[...]
]
[read] MD5 and SHA1 hashes: len = 1024
[...]
[Raw read]: length = 5
[...]
[Raw read]: length = 8
[...]
main, READ: TLSv1 Handshake, length = 8
*** CertificateRequest
Cert Types: RSA
Cert Authorities:
<Empty>
[read] MD5 and SHA1 hashes: len = 8
[...]
[Raw read]: length = 5
[...]
[Raw read]: length = 4
[...]
main, READ: TLSv1 Handshake, length = 4
*** ServerHelloDone
[read] MD5 and SHA1 hashes: len = 4
[...]
*** Certificate chain
***
*** ClientKeyExchange, RSA PreMasterSecret, TLSv1
[write] MD5 and SHA1 hashes: len = 269
[...]
main, WRITE: TLSv1 Handshake, length = 269
[Raw write]: length = 274
[...]
SESSION KEYGEN:
PreMaster Secret:
[...]
CONNECTION KEYGEN:
Client Nonce:
[...]
Server Nonce:
[...]
Master Secret:
[...]
Client MAC write Secret:
[...]
Server MAC write Secret:
[...]
Client write key:
[...]
Server write key:
[...]
Client write IV:
[...]
Server write IV:
[...]
main, WRITE: TLSv1 Change Cipher Spec, length = 1
[Raw write]: length = 6
[...]
*** Finished
verify_data: { 212, 27, 4, 13, 87, 128, 70, 120, 43, 97, 111, 135 }
***
[write] MD5 and SHA1 hashes: len = 16
[...]
Padded plaintext before ENCRYPTION: len = 40
[...]
main, WRITE: TLSv1 Handshake, length = 40
[Raw write]: length = 45
[...]
[Raw read]: length = 5
[...]
[Raw read]: length = 2
[...]
main, READ: TLSv1 Alert, length = 2
main, RECV TLSv1 ALERT: fatal, handshake_failure
%% Invalidated: [Session-1, SSL_RSA_WITH_3DES_EDE_CBC_SHA]
main, called closeSocket()
main, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
答
我是缺少客户端的证书必须由经过认证签名请求(CSR)的服务器生成的事实。
的过程是:
- 产生一个密钥对(经由密钥工具-genkey)
- 生成PKCS#10 CSR(经由密钥工具-certreq)
- 将CSR发送到有关当局
- 取回SSL证书
感谢您的评论,这些评论帮助我提高了我对ssl的理解。不发送任何证书
答
的证书颁发机构和证书链都是空的。
这意味着服务器信任库中没有可信的CA证书。
我的客户也不要扔回去了他的证书。
没有发回他的证书。抛出异常,而不是证书。不要滥用标准术语。他不允许发送证书,除非他的证书被服务器称为他信任的证书请求消息中的一个CA信任。
答
客户端设备两件事情:1。 服务器没有要求任何证书(所以没有CertificateRequest) 2.服务器已请求证书,但密钥库不要求有证书。
我很惊讶做CRL检查(在PKCS#7或其他任何东西)做任何SSL/TLS连接。 CRL获取和OCSP的最佳做法是使用普通HTTP或其他简单的LDAP,以避免无限循环。 * data *(CRL或OCSP主体)已经签名,不需要进一步的完整性或通常的任何保密性。 –
“ServerHelloDone”后面的'Certificate chain'消息中是否有任何内容(不确定是否删除了一些行)。 – Bruno
证书链是空的。 – jBravo