I’ve just gone through the grief of making changes to an old system of mine that employed WSE 3 and WS_SecurityPolicy in particular to provide a secure link between a front end system and a back end service. ARRRRRRGGGGH – it took way too long, and I realised there just wasn’t enough information around to get at all of the issues in one go. In fact, I’ll probably forget some myself as I put this post together. But here’s hoping that this might be of help to some people.
If you’re working with WSE 3.0 your probably already thinking “why don’t I just move straight to WCF?”. Of course, you may not have a choice, so for all of us suckers victims developers, here’s some clues when you get a whole raft of WSE error messages – such as the following:
- WSE101: An asynchronous operation raised an exception.
If you see this one, the first thing to check is – “is my service actually running?”. And you need to answer that question in all its permutations, such as “is my service actually registered with IIS properly?”
- WSE600: Unable to unwrap a symmetric key using the private key of an X.509 certificate. Please check if the account ‘NT AUTHORITY\NETWORK SERVICE’ has permissions to read the private key of certificate with subject name …
This one is actually moderately useful in that it actually means what it says. Your system can’t find the private key of the certificate that you are using, and it’s probably a permissions issue.
Now here’s the kicker: if you give the correct permissions to your certificate you can’t just copy that certificate, with those permissions, to some new location in the certificate store. You must export and then import the certificate and even then you should check the permissions on each individual certificate.
Thanks to Julie Lerman’s Blog of 16 Jan, 2006 for that one.
- WSE841: An error occured processing an outgoing fault response
A not so useful message. This one does often occur with WSE600, and the solution does seem to relate to sorting out permissions to the certificates involved.
- WSE910: An error happened during the processing of a response message. …
Another not so useful message. Some of the forum posts about this one seem to indicate that it is a problem with certificates, that is, the wrong certificates. So the answer is: use every certificate tool that you have and clean out every copy of the offending certificates wherever they may be lurking, then import the correct certificates into the correct places.
However, here’s another really obscure cause of this problem, that did catch me out – twice. If you generate your own certificate you can end up with the two keys not being exactly the same size in bits. Maybe they should be 512/512, but instead you’ve got 511/513. You can identify this if you export your certificate with the private key, but you can never import it with one. If this is the case then very carefully get rid of every copy, everywhere of the offending certificate, and then generate a new one.
- WSE2008: EncryptedKeyToken is expected but not present in the security header
First of all check that you are actually calling the SetPolicy method provided by the Web Service Proxy class and passing it the correct policy name, this will definitely help.
Next, it seems that everyone has problems with typos in this area, so make sure that the policy name you’re using in your code EXACTLY matches the policy name in your policies file. Having that one wrong can lead to this error as a symptom of that problem.
- WSE2013: X509TokenProvider is unable to provide an X.509 token. There are no certificates in the certificate store that match the find value of …
So what’s the difference between this one and WSE600? In some respects not much, however this one seems to bite when you move from your development machine to your server. So after having sorted out permissions to your certificate what else could be wrong? Abishek’s answer to his own question in his MSDN Forum post of 7 May, 2007 provides another useful part of the answer, albeit indirectly.
When you move the client part of your system to the server you’ll probably think that your client can still use the “CurrentUser” part of the certificate store. However, IIS almost certainly doesn’t have access to that, so your policies file will need to actually point to the “LocalMachine” certificate store instead, with the certificate in the correct place.
Here’s some other recommendations I have, and they can be summarised as “Use ALL of the tools that you can get your hands on“.
- From WSE you have the Certificates Tool and the Configuration Tool. In particular in the Configuration Tool, the “Replace” button against your application policy invokes an extremely useful wizard that does a lot of the heavy lifting of correctly setting your policies file.
- The Certificate Plug-in for MMC, will enable you to get at pretty much all of the certificates, although you’ll always have to add at least two instances (My User and Computer and you may need more). Remember, never copy certificates from one part of the certificate store to another using this tool, because the access permissions just won’t be copied with them. There’s only one time to break that rule, if you are using a self generated certificate then you should copy it to the LocalMachine/Trusted Root, otherwise you could end up with some of the error messages above.
- CertMgr, which comes with the Windows SDK. This is almost like two tools, the command line version does so many different things from the GUI version. Another vital tool in finding where reject certificates may be lurking.
- WinHttpCertCfg, which you’ll find with the WSE samples. This one will help you sort out the access privileges properly.
Here’s some articles I recommend reviewing if you’re having problems:
Protect Your Web Services Through The Extensible Policy Framework In WSE 3.0
