在cxf和IIS之间进行客户端身份验证的SSL导致SocketException和SocketTimeoutException [英] ssl with client authentication between cxf and IIS resulting in SocketException and SocketTimeoutException

问题描述

因此，最近几天，我一直在尝试从Tomcat6 / Camel / Cxf到IIS6的两种方式的SSL设置。

So, I've been wrestling with a two way ssl setup between Tomcat6/Camel/Cxf to IIS6 the last few days.

快速概述：我有一个cxf使用者在Tomcat的Camel中运行，该使用者调用由IIS上的第三方托管的Web服务。第三方使用的是有效证书，而我们使用的是自签名证书。 IIS配置为要求客户端身份验证。

A quick overview: I have a cxf consumer running in Camel in Tomcat, which calls a webservice hosted with a third party on IIS. The third party is using a 'valid' certificate, whereas we are using a self-signed certificate. IIS is configured to require client authentication.

我已经到了正确配置cxf并且正在执行相互认证的地步。

I've gotten to the point where cxf is configured correctly, and mutual authentication is being performed.

有些陷阱我需要修复才能到达那里：

Some gotcha's I needed to fix to get there:

• allowUnsafeRenegotiation = true


• https.protocols = TLSv1（否则Java会在握手过程中发送SSLv2客户端问候）


• 删除我所使用的默认密码套件过滤器从大多数CXF示例复制而来，它太严格了。

所有证书，防火墙设置等都是正确的，因为我能够做到使用curl调用第三方，我会收到有效的SOAP响应。

All certificates, firewall settings etc. are correct, as I'm able to do a call to the third party using curl and I get a valid SOAP response back.

问题：我收到超时异常从我的应用程序发送SOAP POST消息时。

The problem: I get a timeout exception when sending a SOAP POST message from my application.

查看ssl调试日志中有一些奇怪的错误（我试图删除所有不必要的内容）：

Looking into the ssl debug log there are some strange errors (I tried to remove all unnecessary stuff):

trigger seeding of SecureRandom
done seeding SecureRandom
Allow unsafe renegotiation: true
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
http-9203-1, setSoTimeout(120000) called
%% No cached client session
*** ClientHello, TLSv1
http-9203-1, WRITE: TLSv1 Handshake, length = 111
http-9203-1, READ: TLSv1 Handshake, length = 2454
*** ServerHello, TLSv1
RandomCookie:  GMT: 1354816328 bytes = { 63, 194, 181, 182, 56, 251, 234, 198, 234, 92, 162, 175, 243, 127, 133, 182, 0, 237, 102, 9, 37, 133, 141, 3, 175, 120, 34, 92 }
Session ID:  {36, 10, 0, 0, 166, 131, 36, 81, 251, 181, 83, 154, 76, 240, 235, 82, 39, 135, 239, 235, 231, 195, 17, 225, 220, 59, 105, 207, 116, 185, 114, 172}
Cipher Suite: SSL_RSA_WITH_RC4_128_MD5
Compression Method: 0
***
Warning: No renegotiation indication extension in ServerHello
%% Created:  [Session-1, SSL_RSA_WITH_RC4_128_MD5]
** SSL_RSA_WITH_RC4_128_MD5
*** Certificate chain
***
Found trusted certificate:
*** ServerHelloDone
*** ClientKeyExchange, RSA PreMasterSecret, TLSv1
http-9203-1, WRITE: TLSv1 Handshake, length = 262
http-9203-1, WRITE: TLSv1 Change Cipher Spec, length = 1
*** Finished
verify_data:  { 124, 172, 175, 239, 103, 187, 134, 164, 206, 241, 145, 41 }
***
http-9203-1, WRITE: TLSv1 Handshake, length = 32
http-9203-1, READ: TLSv1 Change Cipher Spec, length = 1
http-9203-1, READ: TLSv1 Handshake, length = 32
*** Finished
verify_data:  { 84, 207, 104, 255, 19, 151, 27, 11, 159, 84, 124, 216 }
***
%% Cached client session: [Session-1, SSL_RSA_WITH_RC4_128_MD5]
[read] MD5 and SHA1 hashes:  len = 16
0000: 14 00 00 0C 54 CF 68 FF   13 97 1B 0B 9F 54 7C D8  ....T.h......T..
Padded plaintext before ENCRYPTION:  len = 365
0000: 50 4F 53 54 20 2F 69 73   61 2E 64 6C 6C 2F 41 43  POST /isa.dll/AC
http-9203-1, WRITE: TLSv1 Application Data, length = 365
Padded plaintext before ENCRYPTION:  len = 1200
0000: 3C 73 6F 61 70 3A 45 6E   76 65 6C 6F 70 65 20 78  <soap:Envelope x
http-9203-1, WRITE: TLSv1 Application Data, length = 1200
default-workqueue-1, READ: TLSv1 Handshake, length = 20

这是没有客户端身份验证的第一次握手（因为IIS使用重新协商来获取客户端证书）。请注意，已经尝试过首次发布SOAP消息（那是正常的吗？）。

This is the first handshake without client authentication (as IIS is using re-negotiation to get the client certificate). Note that a first attempt to post the SOAP message is already been made (is that normal?).

Allow unsafe renegotiation: true
Allow legacy hello messages: true
Is initial handshake: false
Is secure renegotiation: false
*** HelloRequest (empty)
Warning: continue with insecure renegotiation
%% Client cached [Session-1, SSL_RSA_WITH_RC4_128_MD5]
%% Try resuming [Session-1, SSL_RSA_WITH_RC4_128_MD5] from port 58460
*** ClientHello, TLSv1
default-workqueue-1, WRITE: TLSv1 Handshake, length = 159
default-workqueue-1, READ: TLSv1 Handshake, length = 5416
*** ServerHello, TLSv1
%% Created:  [Session-2, SSL_RSA_WITH_RC4_128_MD5]
** SSL_RSA_WITH_RC4_128_MD5
*** Certificate chain
***
Found trusted certificate:
*** CertificateRequest
*** ServerHelloDone
matching alias: servercert
*** Certificate chain
*** ClientKeyExchange, RSA PreMasterSecret, TLSv1
default-workqueue-1, WRITE: TLSv1 Handshake, length = 909
*** CertificateVerify
default-workqueue-1, WRITE: TLSv1 Handshake, length = 150
[Raw write]: length = 155
default-workqueue-1, WRITE: TLSv1 Change Cipher Spec, length = 17
*** Finished
verify_data:  { 242, 160, 100, 95, 172, 14, 166, 71, 158, 148, 220, 42 }
***
default-workqueue-1, WRITE: TLSv1 Handshake, length = 32
default-workqueue-1, READ: TLSv1 Change Cipher Spec, length = 17
default-workqueue-1, READ: TLSv1 Handshake, length = 32
*** Finished
verify_data:  { 115, 32, 183, 236, 113, 63, 144, 117, 126, 132, 150, 67 }
***
%% Cached client session: [Session-2, SSL_RSA_WITH_RC4_128_MD5]
default-workqueue-1, handling exception: java.net.SocketException: Connection reset
%% Invalidated:  [Session-2, SSL_RSA_WITH_RC4_128_MD5]
default-workqueue-1, SEND TLSv1 ALERT:  fatal, description = unexpected_message
default-workqueue-1, WRITE: TLSv1 Alert, length = 18
default-workqueue-1, Exception sending alert: java.net.SocketException: Broken pipe
default-workqueue-1, called closeSocket()
default-workqueue-1, called close()
default-workqueue-1, called closeInternal(true)

第二次握手发送客户端证书到服务器，我删除了详细的日志记录，但是找到并确定了证书。如您所见，握手已经以错误结束（没有时间延迟）。

The second handshake sends the client certificate to the server, I removed the detailed logging but the certificate was found and ok-ed. As you can see this handshake already ends with an error (without any delay in time).

Allow unsafe renegotiation: true
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
default-workqueue-1, setSoTimeout(120000) called
%% No cached client session
*** ClientHello, TLSv1
default-workqueue-1, WRITE: TLSv1 Handshake, length = 111                                      
default-workqueue-1, READ: TLSv1 Handshake, length = 2454
*** ServerHello, TLSv1
Warning: No renegotiation indication extension in ServerHello
%% Created:  [Session-3, SSL_RSA_WITH_RC4_128_MD5]
** SSL_RSA_WITH_RC4_128_MD5
***
Found trusted certificate:
*** ServerHelloDone
*** ClientKeyExchange, RSA PreMasterSecret, TLSv1
default-workqueue-1, WRITE: TLSv1 Handshake, length = 262
... no IV used for this cipher
default-workqueue-1, WRITE: TLSv1 Change Cipher Spec, length = 1
*** Finished
verify_data:  { 130, 65, 225, 31, 41, 14, 21, 42, 102, 176, 151, 245 }
***
default-workqueue-1, WRITE: TLSv1 Handshake, length = 32
default-workqueue-1, READ: TLSv1 Change Cipher Spec, length = 1
default-workqueue-1, READ: TLSv1 Handshake, length = 32
*** Finished
verify_data:  { 125, 78, 165, 103, 115, 60, 111, 169, 180, 174, 0, 169 }
***
%% Cached client session: [Session-3, SSL_RSA_WITH_RC4_128_MD5]
default-workqueue-1, WRITE: TLSv1 Application Data, length = 365
default-workqueue-1, handling exception: java.net.SocketTimeoutException: Read timed out
default-workqueue-1, called close()
default-workqueue-1, called closeInternal(true)
default-workqueue-1, SEND TLSv1 ALERT:  warning, description = close_notify
default-workqueue-1, WRITE: TLSv1 Alert, length = 18

然后执行第三次握手（正常？），然后再次完成SOAP消息的POST（t他写了申请日期）。在POST之后，日志记录将一直等到套接字超时过期（我将其设置为2分钟或10秒，没有影响）之后，我收到SocketTimeoutException。我尝试切换到SSLv3或2，但是结果完全一样。

Then a third handshake is performed (normal?), and again a POST of the SOAP message is done (the write of the application date). After that POST the logging waits until the socket timeout expires (I've put it on 2 minutes or 10 secs, doesn't make a difference), after which I get a SocketTimeoutException. I tried switching to SSLv3 or 2, but that gives exactly the same result.

有什么想法会导致这种行为吗？

Any ideas what it causing this behaviour?

推荐答案

有人曾经遇到过同样的问题，这个最终为我解决了。我要求我们的第三方将此标志设置为true，因为我们彼此之间的交流不应该是问题。将标志设置为true将禁用重新协商，从而跳过ssl设置中出错的部分。

Should anyone ever encounter this same problem, this solved it eventually for me. I asked our third party to set this flag to true, since we only communicate with each other that shouldn't be a problem. Setting the flag to true disables renegotation, thus skipping the part in the ssl setup where it went wrong.

这篇关于在cxf和IIS之间进行客户端身份验证的SSL导致SocketException和SocketTimeoutException的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！