2015-10-19 95 views
2

我在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 
+0

我很惊讶做CRL检查(在PKCS#7或其他任何东西)做任何SSL/TLS连接。 CRL获取和OCSP的最佳做法是使用普通HTTP或其他简单的LDAP,以避免无限循环。 * data *(CRL或OCSP主体)已经签名,不需要进一步的完整性或通常的任何保密性。 –

+0

“ServerHelloDone”后面的'Certificate chain'消息中是否有任何内容(不确定是否删除了一些行)。 – Bruno

+0

证书链是空的。 – jBravo

回答

1

我是缺少客户端的证书必须由经过认证签名请求(CSR)的服务器生成的事实。

的过程是:

  1. 产生一个密钥对(经由密钥工具-genkey)
  2. 生成PKCS#10 CSR(经由密钥工具-certreq)
  3. 将CSR发送到有关当局
  4. 取回SSL证书

感谢您的评论,这些评论帮助我提高了我对ssl的理解。不发送任何证书

0

的证书颁发机构和证书链都是空的。

这意味着服务器信任库中没有可信的CA证书。

我的客户也不要扔回去了他的证书。

没有发回他的证书。抛出异常,而不是证书。不要滥用标准术语。他不允许发送证书,除非他的证书被服务器称为他信任的证书请求消息中的一个CA信任。

+0

但是,如果服务器不信任任何人,我还可以建立SSL连接吗?这是我的问题吗? – jBravo

+0

我编辑了我的帖子来纠正我的术语错误。对不起。 – jBravo

+0

如果服务器没有人信任,则没有人可以通过客户端证书进行身份验证。然而,你的服务器正在请求一个,并且在没有连接的时候放弃连接。你只需要下决心是否要客户证书,如果是的话,你会信任哪些发行人。 – EJP

0

客户端设备两件事情:1。 服务器没有要求任何证书(所以没有CertificateRequest) 2.服务器已请求证书,但密钥库不要求有证书。