Microsoft KB Archive/939760

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

Article ID: 939760

Article Last Modified on 7/31/2007

-

APPLIES TO


 * Microsoft Visual Studio 2005 Team Suite
 * Microsoft Visual Studio 2005 Team Foundation Server
 * Microsoft Visual Studio 2005 Team System Test Edition
 * Microsoft Visual Studio 2005 Team Edition for Database Professionals
 * Microsoft Visual Studio 2005 Team Edition for Software Architects
 * Microsoft Visual Studio 2005 Team Edition for Software Developers
 * Microsoft Visual Studio 2005 Team Edition for Software Testers
 * Microsoft Visual Studio 2005 Standard Edition
 * Microsoft Visual Studio 2005 Professional Edition
 * Microsoft Visual Studio 2005 Express Edition

-



SYMPTOMS
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

Date: 5/19/2007

Time: 3:30:00 PM

User: N/A

Computer: ServerName

Description:

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.



CAUSE
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



WORKAROUND
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.    Note For more information about the how to use the stateless SecurityContextToken object together with the DPAPI for protection, see the &quot;More Information&quot; 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.       bBwPfItvKp3b6TNDq+14qs58VJQ=   </serviceToken> </tokenIssuer> </microsoft.web.services3>

<div class="status_section">

STATUS
Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the &quot;Applies to&quot; section.

<div class="moreinformation_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 &quot;References&quot; 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.

<div class="references_section">