0

We have a WCF service under IIS that is protected by Transport security (SSL) with client certificates (not the message WS-Security, but by IIS itself). I have added the certificate to wso2carbon.jks Whenever Send mediator is executed the request times out. IIS log shows only error 500.0. If in IIS configuration I set to ignore client certificates everything works fine. Also coded Java Axis2 and .Net clients work fine with turned on certificates on ISS.

Most probably I missed something in the call. Is WS-policy required for such case? I would appreciate any help.

Community
  • 1
  • 1
adnecs
  • 175
  • 1
  • 10
  • Additional info - looks like it is carbon transport problem. Checking wireshark all transports are stuck on handshake in Hello Request So server sends Hello to ESB, and communication is stuck. Only CommonsHTTPTransportSender was able to complete handshake with the server (still didn't send certificate though) So can it be a problem for PassThrough and NIO http transports in Carbon? – adnecs Mar 14 '13 at 09:00

2 Answers2

2

Finally found a workaround.

Solution Enable SSLAlwaysNegoClientCert on IIS. Here is a good post: Make IIS require SSL client certificate during initial handshake

Reason: IIS by default will renegotiate SSL if client accesses protected resource. NIO and HttpPathThrough transports do not allow renegotiation (which kind of makes sense as it is security vulnerability). So IIS doesn't get Client Hello and issues error 500 (to WSO2 guys, why the TryIt client hangs till timeout then?)

Remark: not always can we make changes on IIS side so it'd be much better if transports available in WSO2 ESB would be more flexible as for allowing renegotiation (maybe I missed where to configure it...)

Community
  • 1
  • 1
adnecs
  • 175
  • 1
  • 10
  • Good to hear that you found a workaround for this. But did you try Start ESB with following additional parameter, -Dsun.security.ssl.allowUnsafeRenegotiation=true (I found it in the jira which you pointed me to). Jira says it is not working. But just wanted to check whether you tried it. – Amila Maharachchi Mar 15 '13 at 07:11
  • Thx. This parameter works only with Core Http transport and didn't affect NIO or passthrough. So it didn't help in this case. – adnecs Mar 15 '13 at 15:29
  • 1
    I looked further into this and found that the issue still exists. WSO2 ESB team is aware of this and this is in their roadmap to fix properly. They also suggested to use the CallOut mediator as a workaround for this. – Amila Maharachchi Mar 16 '13 at 17:04
  • Has there been any resolution on this? I'm facing the exact same issue. – Manoj N V Mar 09 '15 at 16:34
0

In this scenario, WSO2 ESB is acting as the client. Therefore, you need to import the certificate to the client-truststore.jks which is in repository/resources/security folder of WSO2 ESB. Then your service invocation should work.

Amila Maharachchi
  • 2,121
  • 2
  • 15
  • 21
  • 1
    Yes, it should be in the client-truststore.jks. You can enable SSL debugginh in ESB and see what goes wrong at which point in the ESB. There are resources which will explain how to enable SSL debug logs. – Amila Maharachchi Mar 14 '13 at 17:58
  • From all debugging it looks like the problem is that both PassThrough and NIO https transports do not support (bug?) SSL renegotiation. When client makes a request to certificate-protected resource server requests renegotiation by sending Hello request. Clint doesn't respond and all is stuck. Core http transport completes renegotiation fine. Found bug opened by you wso2.org/jira/browse/CARBON-11041 Seems to be related. Were you able to solve the issue? It is a really blocker for us go on, so I'd greatly appreciate help. – adnecs Mar 15 '13 at 02:16