WCF Receive "Primary Signature Must Be Encrypted". from FaultContract with ProtectionLevel.None
I have an existing asp.net application that talks about loading balanced wcf services (iis is hosted in an application pool running under an account configured as servicePrincipalName, etc.). The wcf services return multiple custom faults, all of which are defined with FaultContract (typeof (x), ProtectionLevel = ProtectionLevel.None) - these services are not exposed to the public. The client refers to the generated service classes to access the services.
This works great, but now with the latest code base, we get "Primary signature must be encrypted". exceptions on the client when the service returns one of these errors. Service code and configuration do not change (at least the legacy parts that generate errors). The generated client service reference code looks the most modified (it is often deleted and recreated).
The security configuration has not changed for over a year. All updates are pretty current. We tested this in three environments, and as soon as we deploy a new codebase, errors start throwing exceptions. It looks like it should be in the generated classes, but they are generated by Visual Studio, so this is very puzzling.
Sounds familiar to everyone? Any suggestions?
Update. Removing the ProtectionLevel attribute and allowing it by default makes the problem go away, but I'm curious as to why specifying None fails. This may be at odds with the default contract level or service contract, but these values โโhave not changed in the last year, so they do not explain why what worked now is not working.
Update: for what it's worth, this change in code generation happened between 2.0.50727.3053 and 2.0.50727.3082 (as per the runtime comment in the generated code).
a source to share
I have not experienced this problem myself, but my question is, why are you specifying "ProtectionLevel = None" in your fault contract? Is there a specific reason for this?
If not, I highly recommend not specifying that - by default - ProtectionLevel = EncryptAndSign is generally the best choice. Try it if you don't have a very strong and obvious reason.
Mark
a source to share