MessageSecurityException on the second request if my client is idle for a while after the first request
It may be two cause:
(i) – The session has timed out
(ii) – the Web server that is hosting the service is recycled
session is valid until the service times out. When the service does not receive a request from the client within the period of time specified in the service’s binding (ReceiveTimeout), the service terminates the security session. Subsequent client messages result in the MessageSecurityException. The client must re-establish a secure session with the service to send future messages or use a stateful security context token. Stateful security context tokens also allow a secure session to survive a Web server being recycled. For more information about using stateful secure context tokens in a secure session, see How to: Create a Stateful Security Context Token for a Secure Session. Alternatively, you can disable secure sessions. When you use the WsHttpBinding binding, you can set the establishSecurityContext property to false to disable secure sessions. To disable secure sessions for other bindings, you must create a custom binding. For details about creating a custom binding, see How to: Create a Custom Binding Using the SecurityBindingElement. Before you apply any of these options, you must understand your application’s security requirements.
Getting exception System.Security.Cryptography.CryptographicException
This commonly occurs after changing the user account under which the IIS worker process runs. For example, in Windows XP, if you change the default user account that the Aspnet_wp.exe runs under from ASPNET to a custom user account, you may see this error. If using a private key, the process that uses it will need to have permissions to access the file storing that key.
If this is the case, you must give read access privileges to the process’s account for the file containing the private key. For example, if the IIS worker process is running under the Bob account, then you will need to give Bob read access to the file containing the private key.
For more information about how to give the correct user account access to the file that contains the private key for a specific X.509 certificate, see How to: Make X.509 Certificates Accessible to WCF.
Getting an EndpointNotFoundException
If you are using a tracing tool that is not the system-provided WCF tracing mechanism and you receive an EndpointNotFoundException that indicates that there was an address filter mismatch, you need to use the ClientViaBehavior class to direct the messages to the tracing utility and have the utility redirect those messages to the service address. The ClientViaBehavior class alters the Via addressing header to specify the next network address separately from the ultimate receiver, indicated by the To addressing header. When doing this, however, do not change the endpoint address, which is used to establish the To value.
The following code example shows an example client configuration file
<endpoint address=http://localhost:8000/MyServer/ binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IMyContract" behaviorConfiguration="MyClient" contract="IMyContract" name="WSHttpBinding_IMyContract"> </endpoint> <behaviors> <endpointBehaviors> <behavior name="MyClient"> <clientVia viaUri="http://localhost:8001/MyServer/"/> </behavior> </endpointBehaviors> </behaviors>