Connect with client authentication with SSL

I have created a web service connector (as consumer) to an external service. The web service requires use of client authentication with SSL. I´ve got the external partners certificate, converted it from .pfx to der and managed to successfully import it into IS client certificates for Administrators and for SSL Authentication. I have verified that the PEM-file that was produced when converting to DER contains both public and private keys.

I restarted the IS after importing certificates.

If i try to run one of the newly created connectors to test communication I get the response:

com.wm.driver.comm.b2b.WmCommException: [[ Peer sent alert: Alert Fatal: bad certificate] Peer sent alert: Alert Fatal: bad certificate] [ Peer sent alert: Alert Fatal: bad certificate] Peer sent alert: Alert Fatal: bad certificate

After this I downloaded the external companies CA certificate from the site containing the WSDL and put it in IS CA directory.

No change.

After that I added a WS Security Handler with digital signature policy. Now i get this failure result when executing connector: WS Security processing failed : Unable to resolve private key for signing or decrypting the message

Am I barking up the wrong tree here? Is there another or better way to enable client authorization?

I had to manually download the WSDL and change the XSD references to be able to create the web service descriptor. Also, In Firefox i couldn´t even view the WSDL before importing the previous mentioned certificate so that must be some kind of proof that there is nothing wrong with the certificate I´m using. Just the way I´m using it perhaps :wink:

I hope anyone know how to do this because I feel that the documentation doesn´t give me any answers nor does google.

No ideas?

If you’re doing client authentication, and you’re the client, then you’ll need to create a cert to give to the partner so they can validate you.

(hijacking Rickard’s post here…:wink:
Hi Reamon

The client certificate was provided by the partner, so I guess they already know who we are. The error message regarding the private key makes me a bit confused. WS Security processing failed : Unable to resolve private key for signing or decrypting the message

Another thing: How does the IS know which client certificate to use since we have several of those defined in the IS? The server certificate (public parter cert) is signed using the same CA cert as our client certificate - is that how the IS knows which client cert to send?

Best regards,

You’ll want to review the web for details on the TLS/SSL handshake and the exchange of certificates.

The (public) cert given to you by the partner is for you to be able to validate/trust them. For them to be able to validate you, you’ll need to provide them with your public cert.

I’ve never had to send a public cert to any partner in order to achieve an ssl session (when we’re the client/consumer), the only thing needed is their public cert in our trusted CA’s folder.

This is like a normal ssl session, but with the requirement to send a client certificate (which was provided by the partner) in order to authenticate ourself.

Does it make sense to you or are we way off track here… :p:


Right. To simply establish a session you don’t need to exchange certs ahead of time at all. You just need your trusted CA store to trust whomever signs the server cert that is used during the handshake when you connect.

But you mentioned that this connection needs client authentication. In order for the partner to validate who you are, you provide them with your cert, not the other way around. They use your public cert to confirm that you (and not some spoofer) are the party connecting to them.

The cert they sent you is for you to confirm them, not the other way around.

[URL]tls - How does bidirectional authentication using SSL work? - Information Security Stack Exchange has a description that may help. There are others on the web as well.

It sounds logic, but they have not said anything about that - and since our partner provided is with the client certificate I assume they already trusts us (they own the CA certificate which signed the client certificate) - but I’ll see if they need anything more from us.

We created a support ticket as well to see what SAG has to say, I’ll post some new info as soon as we have any progress :slight_smile: