none
SslStream BeginAuthenticateAsServer sometimes fails with “A call to SSPI failed, see inner exception. The context has expired and can no longer be used” error. RRS feed

  • Question

  • Hi,

    I have a .NET 4.0 Server.

    I’m using SslStream with BeginAuthenticateAsServer / EndAuthenticateAsServer APIs

    Most of the SSL handshakes are succeeding, but sometimes the handshake fails with following error message:

    “A call to SSPI failed, see inner exception.”

    And the inner exception is: The context has expired and can no longer be used

    The API is being used as follows:

    sslstream.BeginAuthenticateAsServer(ServerCertificate, false, SslProtocols.Default, false, sm_SslAuthenticateAsServerCallback, this);

    I have also initiated the SslStream object with a RemoteCertificateValidationCallback as follows:

    new SslStreamEx(network_stream, true, sm_ClientCertificateValidationCallback)

    Where the callback is implemented as follows:

    private static bool ClientCertificateValidationCallback(object sender,

                                                                                                    X509Certificate certificate,

                                                                                                    X509Chain chain,

                                                                                                    SslPolicyErrors sslPolicyErrors)

    {           

                            return true;

    }

    Any idea what can cause the SSL handshake to fail with above error message?

    Thanks.

    Sunday, October 26, 2014 10:00 AM

Answers

  • Hi Shmaya,

    >>A call to SSPI failed, see inner exception

    The above error may be caused by the certificate does not be validated as trusted. So please try to check it.
    Besides, please try to enable WCF tracing on the service, it will likely give us all the necessary information to help find the root cause.

    The following configuration taken from MSDN can be applied to enable tracing on your WCF service.

    <configuration>
      <system.diagnostics>
        <sources>
          <source name="System.ServiceModel"
                  switchValue="Information, ActivityTracing"
                  propagateActivity="true" >
            <listeners>
                 <add name="xml"/>
            </listeners>
          </source>
          <source name="System.ServiceModel.MessageLogging">
            <listeners>
                <add name="xml"/>
            </listeners>
          </source>
          <source name="myUserTraceSource"
                  switchValue="Information, ActivityTracing">
            <listeners>
                <add name="xml"/>
            </listeners>
          </source>
        </sources>
        <sharedListeners>
            <add name="xml"
                 type="System.Diagnostics.XmlWriterTraceListener"
                 initializeData="Error.svclog" />
        </sharedListeners>
      </system.diagnostics>
    </configuration>

    Best Regards,
    Amy Peng


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.



    Monday, October 27, 2014 4:42 AM
    Moderator

All replies

  • Hi Shmaya,

    >>A call to SSPI failed, see inner exception

    The above error may be caused by the certificate does not be validated as trusted. So please try to check it.
    Besides, please try to enable WCF tracing on the service, it will likely give us all the necessary information to help find the root cause.

    The following configuration taken from MSDN can be applied to enable tracing on your WCF service.

    <configuration>
      <system.diagnostics>
        <sources>
          <source name="System.ServiceModel"
                  switchValue="Information, ActivityTracing"
                  propagateActivity="true" >
            <listeners>
                 <add name="xml"/>
            </listeners>
          </source>
          <source name="System.ServiceModel.MessageLogging">
            <listeners>
                <add name="xml"/>
            </listeners>
          </source>
          <source name="myUserTraceSource"
                  switchValue="Information, ActivityTracing">
            <listeners>
                <add name="xml"/>
            </listeners>
          </source>
        </sources>
        <sharedListeners>
            <add name="xml"
                 type="System.Diagnostics.XmlWriterTraceListener"
                 initializeData="Error.svclog" />
        </sharedListeners>
      </system.diagnostics>
    </configuration>

    Best Regards,
    Amy Peng


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.



    Monday, October 27, 2014 4:42 AM
    Moderator
  • We have verified that the certificate is trusted.

    We are not using WCF, we use the SslStream on to of a NetworkStream which is a TCP connection.

    Therefore, we didn’t open WCF tracing.

    We have checked the event viewer, and we can see the following errors under SCHANNELS:

    They are coming in pairs:

    1a. An SSL 3.0 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed.

    1b.  A fatal alert was generated and sent to the remote endpoint. This may result in termination of the connection. The TLS protocol defined fatal error code is 40. The Windows SChannel error state is 1205.

    2a.  An TLS 1.0 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed.

    2b.  A fatal alert was generated and sent to the remote endpoint. This may result in termination of the connection. The TLS protocol defined fatal error code is 40. The Windows SChannel error state is 1205.

    we can (sometimes, not all the time) see a correlation between the time we get the error in our server, and the time the events are logged in the event viewer.

    One more thing: The issue is not related to a timeout. We get this error about 200 millisecond after the socket was opened.

    Can the information above help understanding more what is causing the SSPI call failures.

    Monday, November 3, 2014 3:05 PM