Error message when you configure a WSE 3.0-based Web service to use secure conversation in a load-balanced environment: "Key not valid for use in specified state"


Consider the following scenario:
  • You configure a Microsoft Web Services Enhancements 3.0 (WSE 3.0)-based Web service to use secure conversation.
  • You host the Web service in a load-balanced environment.
In this scenario, you may receive the following error message in the Application log:
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:
  • The state of the SecurityContextToken object
  • The cookie of the SecurityContextToken object


To work around this problem, use one of the following methods.

Method 1

Use 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 2

Configure 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.
<statefulSecurityContextToken enabled="false"/>
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 3

Use 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.
<statefulSecurityContextToken enabled="true"/>
<wsse:SecurityTokenReference xmlns:wsse="">
<wsse:KeyIdentifier ValueType="">bBwPfItvKp3b6TNDq+14qs58VJQ=</wsse:KeyIdentifier>


Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.

More Information

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:

309408 How to troubleshoot the Data Protection API (DPAPI)

For more information about Windows Data Protection, visit the following Microsoft Developer Network (MSDN) Web site:For more information about the statefulSecurityContextToken element, visit the following MSDN Web site:

Article ID: 939760 - Last Review: Jul 31, 2007 - Revision: 1