Thursday, March 5, 2009

Cryptic WCF error messages (part 1 of N)

@YaronNaveh


If you are a WCF developer then sooner or later you are going to meet some cryptic error messages. No, they are not as intimidating as “access violation at address FFFFFF” and the blue screen of death, but is “Keyset does not exist“ and the white screen of trace any better?

This is the first out of a serious of posts in which I'll try to diminish the mystery of these errors. This time I’ll examine an X.509 related issue.

The other day I was configuring my WsHttpBinding with X.509 certificates used for digital signature and encryption. When I ran my client application I got that annoying

An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail.

I hurried up and configured WCF tracing on my service only to get

The EncryptedKey clause was not wrapped with the required encryption token 'System.IdentityModel.Tokens.X509SecurityToken'.

This error is not so clear for those of us not familiar with the wire format of web services. However it does contain the essence of the problem: The client and the server are not using matching X.509 certificates. In order for the service to decrypt the message sent by the client it must use an X.509 containing a private key that matches the public key in the X.509 that the client is using for encryption.

Now if you (like me at the time) insist that you are using the correct certificate, I suggest you would double and triple check the X.509 references in your web/app.config. If that doesn't help - remove and reinstall the relevant certificates from the windows certificate store. You’ll be surprised to find out you used an old version of the certificate at the client side or a wrong reference at the server. One common scenario where this can happen is if you are temporarily using the WCF or WSE sample certificates – it seems there are a few versions of them.

@YaronNaveh

What's next? get this blog rss updates or register for mail updates!

2 comments:

Anonymous said...

Thanks for this. I had two different certificates sign by the same CA. I thought that would be OK, but it wasn't. (Might be because client and service were on the same box)

tomas said...

Thanks for the post. This led me to realize that I had to re-generate the certificate "encodedValue" that I was using on my client-side application so that my certificates would match.