Article ID: 939760 - View products that this article applies to.
Consider the following scenario:
Event Type: Error
Event Source: Microsoft WSE 3.0
Event Category: None
Event ID: 0
Time: 3:30:00 PM
System.ApplicationException: WSE841: An error occurred processing an outgoing fault response.
System.Web.Services.Protocols.SoapException: System.Web.Services.Protocols.SoapException: Server was unable to process request.
System.Security.Cryptography.CryptographicException: Key not valid for use in specified state.
This problem occurs because WSE 3.0 cannot be used to protect data in a load-balanced environment.
By default, if you configure the Web service to use secure conversation by setting the EstablishSecurityContext property of the policy to True, WSE 3.0 uses the stateful SecurityContextToken object. This operation uses the Data Protection API (DPAPI) to encode and decode the following:
To work around this problem, use one of the following methods.
Method 1Use the Sticky Sessions feature for the load balancer. This operation forces the conversation to be processed completely on a single server in the load-balanced environment. This method avoids the problem.
Method 2Configure the statefulSecurityContextToken element to disable the stateful security tokens of the Web service. For example, use an application configuration file that contains the following code to disable the stateful security tokens.
Note For more information about the how to use the stateless SecurityContextToken object together with the DPAPI for protection, see the "More Information" section.
Method 3Use an X509 certificate or another type of security token instead of the default DPAPI implementation to help secure the SecurityContextToken object. To do this, configure the serviceToken element in the application configuration file of each Web server.
For example, the following code configures the Web service to use an X509 certificate instead of the DPAPI implementation to help secure the SecurityContextToken object.
Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.
WSE 3.0 uses the CurrentUser value of the DataProtectionScope enumeration when WSE 3.0 calls the DPAPI. The DPAPI master key information is stored in the profile of the current user. However, the DPAPI cannot be used together with roaming user profiles. For more information, see the Microsoft Knowledge Base article that is mentioned in the "References" section.
In this scenario, the DPAPI cannot be used with non-roaming user profiles. For example, the local user profile for a user is different on different computers. By default, the master key of the DPAPI expires after 90 days. When the master key of the DPAPI is regenerated, each computer has a different master key in the local copy of the user profile. However, the data that is encrypted by one computer cannot be decrypted by another computer. Therefore, the local copy of the user profile causes the problem.
When you send a SOAP message, the stateful SecurityContextToken object is serialized together with an encrypted key. Only the Web service can retrieve this encrypted key. However, the encrypted key of the stateless SecurityContextToken object is cached by the client and Web service. Therefore, a unique string that represents the cached SecurityContext security token must be sent in the SOAP message. When the caches are available, no problem occurs. However, if you use the stateless SecurityContextToken object, and the application domain that is hosting the Web service is reset, the caches are destroyed. This situation causes a SOAP error.
Note Some virus scanners may cause application domains to be reset.
For more information about the DPAPI, click the following article number to view the article in the Microsoft Knowledge Base:
309408For more information about Windows Data Protection, visit the following Microsoft Developer Network (MSDN) Web site:
(http://support.microsoft.com/kb/309408/ )How to troubleshoot the Data Protection API (DPAPI)
http://msdn2.microsoft.com/en-us/library/ms995355.aspxFor more information about the statefulSecurityContextToken element, visit the following MSDN Web site:
Article ID: 939760 - Last Review: July 31, 2007 - Revision: 1.0
Contact us for more help