none
WCF: Not able to connect to service after enabling TLS 1.2 RRS feed

  • Question

  • We are in process of upgrading our product to use TLS 1.2 version. To do that, we upgraded all the project from .net 4.0 to .net 4.7.1 version and built it, of course, we faced a couple of reference issues but that's all are resolved. But I am seeing one issue, specific to WCF service while opening a channel "((IClientChannel)macroEngineClient).Open();".   

                string retProtocol = System.Net.ServicePointManager.SecurityProtocol.ToString();  // This returns TLS 1.2 at run time
                IMacroEngine macroEngineClient = (IMacroEngine)_macroEngPool.GetClient(GetTokenId(token), WSConstants.MACRO_ENGINE_BINDING_CONFIG, token);

                try
                {
                    if (((IClientChannel)macroEngineClient).State != CommunicationState.Opened)
                    {
                        ((IClientChannel)macroEngineClient).Open();
                    }
                    macroEngineClient.ClearKnownValue(macro);
                }

    Exception: 

    An exception has been thrown by the target of an invocation.
    System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.ServiceModel.Security.SecurityNegotiationException: SOAP security negotiation failed. See inner exception for more details. ---> System.ComponentModel.Win32Exception: The client and server cannot communicate, because they do not possess a common algorithm
       at System.IdentityModel.SspiWrapper.AcquireCredentialsHandle(String package, CredentialUse intent, SecureCredential scc)
       at System.ServiceModel.Security.TlsSspiNegotiation.AcquireDummyCredentials()
       at System.ServiceModel.Security.TlsSspiNegotiation..ctor(String destination, Boolean isServer, SchProtocols protocolFlags, X509Certificate2 serverCertificate, X509Certificate2 clientCertificate, Boolean clientCertRequired)
       at System.ServiceModel.Security.TlsnegoTokenProvider.CreateTlsSspiState(X509SecurityToken token)
       at System.ServiceModel.Security.TlsnegoTokenProvider.CreateNegotiationState(EndpointAddress target, Uri via, TimeSpan timeout)
       at System.ServiceModel.Security.IssuanceTokenProviderBase`1.DoNegotiation(TimeSpan timeout)
       --- End of inner exception stack trace ---


    Based on the exception details, I found a lot of articles to fix the issue but none of them helped. Please let me know what I am doing wrong to fix the issue. 

    Things we already tried- 

    1. Disabling older version of SSL and TLS - https://docs.microsoft.com/en-us/officeonlineserver/enable-tls-1-1-and-tls-1-2-support-in-office-online-server

    2. Disabled RC4 cipher - https://blogs.technet.microsoft.com/srd/2013/11/12/security-advisory-2868725-recommendation-to-disable-rc4/

    3. Added "AppContextSwitchOverrides" config setting as per the link - https://github.com/Microsoft/dotnet/blob/master/Documentation/compatibility/wcf-message-security-unable-to-use-tls1_1-and-tls1_2.md

    4. Set the registry key "SchUseStrongCrypto" to 1.

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SchUseStrongCrypto

    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319


    WCF Federated Service configuration:- 

    <runtime>
    <generatePublisherEvidence enabled="false"/>
        <AppContextSwitchOverrides value="Switch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols=false" />
    </runtime>

    <sources>
    <source name="System.ServiceModel" switchValue="Warning, ActivityTracing">
    <listeners>
    <add type="System.Diagnostics.DefaultTraceListener" name="Default">
    <filter type="" />
    </add>
    <add name="ServiceModelTraceListener">
    <filter type="" />
    </add>
    </listeners>
    </source>
    <source name="System.ServiceModel.MessageLogging" switchValue="Warning, ActivityTracing">
    <listeners>
    <add type="System.Diagnostics.DefaultTraceListener" name="Default">
    <filter type="" />
    </add>
    <add name="ServiceModelMessageLoggingListener">
    <filter type="" />
    </add>
    </listeners>
    </source>
    <source name="Microsoft.IdentityModel" switchValue="Verbose">
    <listeners>
    <add name="xml" type="System.Diagnostics.XmlWriterTraceListener" initializeData="..\MacroEngine_WIFTrace.svclog" />
    </listeners>
    </source>
    </sources>
    <sharedListeners>
    <add initializeData="..\MacroEngine_tracelog.svclog" type="System.Diagnostics.XmlWriterTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" name="ServiceModelTraceListener" traceOutputOptions="Timestamp">
    <filter type="" />
    </add>
    <add initializeData="..\MacroEngine_messages.svclog" type="System.Diagnostics.XmlWriterTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" name="ServiceModelMessageLoggingListener" traceOutputOptions="Timestamp">
    <filter type="" />
    </add>
    </sharedListeners>
    <trace autoflush="true" />
    </system.diagnostics>-->
    <appSettings>
    <add key="IssuerName" value="ActiveSTS"/>
    <add key="SigningCertificateName" value="CN=STS"/>
    <add key="EncryptingCertificateName" value="CN=STS"/>
    <add key="LogLevel" value="0"/>
    </appSettings>

    <connectionStrings/>

    <system.serviceModel>
    <diagnostics>
    <messageLogging logEntireMessage="true" logMessagesAtServiceLevel="true"/>
    </diagnostics>
    <services>
    <service behaviorConfiguration="MacroEngine.Configuration" name="Core.WS.MacroEngine.MacroEngine">
    <endpoint address="IMacroEngine" binding="ws2007FederationHttpBinding" bindingConfiguration="MacroFederationBinding" contract="Core.WS.Contracts.IMacroEngine"/>
    <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
    </service>
    </services>
    <bindings>
    <ws2007FederationHttpBinding>
    <binding name="MacroFederationBinding" receiveTimeout="01:00:00" sendTimeout="01:00:00" maxReceivedMessageSize="262144">
    <readerQuotas maxArrayLength="262144" maxStringContentLength="131072" maxBytesPerRead="32768"/>
      <security mode="Message" />
    </binding>
    </ws2007FederationHttpBinding>
    </bindings>
    <behaviors>
    <serviceBehaviors>
    <behavior name="MacroEngine.Configuration">
    <serviceMetadata httpGetEnabled="true"/>
    <serviceThrottling maxConcurrentCalls="10000" maxConcurrentInstances="2147483647" maxConcurrentSessions="10000"/>
    <serviceDebug includeExceptionDetailInFaults="true"/>
    <serviceCredentials>
    <issuedTokenAuthentication audienceUriMode="Never"></issuedTokenAuthentication>
    <serviceCertificate findValue="cn=STS" storeLocation="LocalMachine" storeName="My" x509FindType="FindBySubjectDistinguishedName"/>
    </serviceCredentials>
    </behavior>
    </serviceBehaviors>
    </behaviors>
    </system.serviceModel>

    <microsoft.identityModel>
    <service name="MacroEngine">
    </service>
    </microsoft.identityModel>
    <startup><supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7.1"/></startup></configuration>

    Client application configuration: 

       <system.serviceModel>
       <bindings>
          <ws2007FederationHttpBinding>
            <binding name="MacroFederationBinding" maxReceivedMessageSize="262144">
              <readerQuotas maxStringContentLength="131072" maxArrayLength="262144" maxBytesPerRead="32768" />
              <security mode="Message">
              </security>
            </binding>
          </ws2007FederationHttpBinding>
        </bindings>
        <client>
          <endpoint address="http://localhost:9001/CourWS/MacroEngine/IMacroEngine" binding="ws2007FederationHttpBinding" bindingConfiguration="MacroFederationBinding" contract="Core.WS.Contracts.IMacroEngine" name="MacroFederationBinding">
            <identity>
              <dns value="STS" />
            </identity>
          </endpoint>
      </system.serviceModel>

    Full Exception detail- 

    An exception has been thrown by the target of an invocation.
    System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.ServiceModel.Security.SecurityNegotiationException: SOAP security negotiation failed. See inner exception for more details. ---> System.ComponentModel.Win32Exception: The client and server cannot communicate, because they do not possess a common algorithm
       at System.IdentityModel.SspiWrapper.AcquireCredentialsHandle(String package, CredentialUse intent, SecureCredential scc)
       at System.ServiceModel.Security.TlsSspiNegotiation.AcquireDummyCredentials()
       at System.ServiceModel.Security.TlsSspiNegotiation..ctor(String destination, Boolean isServer, SchProtocols protocolFlags, X509Certificate2 serverCertificate, X509Certificate2 clientCertificate, Boolean clientCertRequired)
       at System.ServiceModel.Security.TlsnegoTokenProvider.CreateTlsSspiState(X509SecurityToken token)
       at System.ServiceModel.Security.TlsnegoTokenProvider.CreateNegotiationState(EndpointAddress target, Uri via, TimeSpan timeout)
       at System.ServiceModel.Security.IssuanceTokenProviderBase`1.DoNegotiation(TimeSpan timeout)
       --- End of inner exception stack trace ---

    Server stack trace: 
       at System.ServiceModel.Security.IssuanceTokenProviderBase`1.DoNegotiation(TimeSpan timeout)
       at System.ServiceModel.Security.SspiNegotiationTokenProvider.OnOpen(TimeSpan timeout)
       at System.ServiceModel.Security.TlsnegoTokenProvider.OnOpen(TimeSpan timeout)
       at System.ServiceModel.Security.WrapperSecurityCommunicationObject.OnOpen(TimeSpan timeout)
       at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
       at System.ServiceModel.Security.CommunicationObjectSecurityTokenProvider.Open(TimeSpan timeout)
       at System.ServiceModel.Security.SymmetricSecurityProtocol.OnOpen(TimeSpan timeout)
       at System.ServiceModel.Security.WrapperSecurityCommunicationObject.OnOpen(TimeSpan timeout)
       at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
       at System.ServiceModel.Channels.SecurityChannelFactory`1.ClientSecurityChannel`1.OnOpen(TimeSpan timeout)
       at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
       at System.ServiceModel.Security.SecuritySessionSecurityTokenProvider.DoOperation(SecuritySessionOperation operation, EndpointAddress target, Uri via, SecurityToken currentToken, TimeSpan timeout)
       at System.ServiceModel.Security.SecuritySessionSecurityTokenProvider.GetTokenCore(TimeSpan timeout)
       at System.IdentityModel.Selectors.SecurityTokenProvider.GetToken(TimeSpan timeout)
       at System.ServiceModel.Security.SecuritySessionClientSettings`1.ClientSecuritySessionChannel.OnOpen(TimeSpan timeout)
       at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
       at System.ServiceModel.Channels.ServiceChannel.OnOpen(TimeSpan timeout)
       at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
       at System.ServiceModel.Channels.CommunicationObject.Open()

    Exception rethrown at [0]: 
       at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
       at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
       at System.ServiceModel.ICommunicationObject.Open()
       at Courion.WSClients.SessionManagement.CourWSSession.ClearKnownValue(String RelyingPartyURI, IMacroDescriptor macro) in E:\Projects\AAS\WSClients\Courion.WSClients.SessionManagement\CourWSSession.cs:line 337
       at Courion.Aspx.Portal.SessionManagement.CourAspxSession.ClearKnownValue(HttpSessionState SessionState, String Macro) in E:\Projects\AAS\Products\Clients\AspxCodeBehind\Courion.Aspx.Portal.SessionManagement\CourAspxSession.cs:line 584
       at Courion.Aspx.Portal.SessionManagement.CourAspxSession.ClearKnownValue(String Macro) in E:\Projects\AAS\Products\Clients\AspxCodeBehind\Courion.Aspx.Portal.SessionManagement\CourAspxSession.cs:line 558
       at Courion.Portal.PortalApplication.Application_PreRequestHandlerExecute() in E:\Projects\AAS\Products\Clients\PortalFramework\PortalFramework\Global.asax.cs:line 170
       --- End of inner exception stack trace ---
       at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
       at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
       at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
       at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
       at System.Web.Util.ArglessEventHandlerProxy.Callback(Object sender, EventArgs e)
       at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
       at System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step)
       at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

    Tuesday, January 9, 2018 9:31 PM

All replies

  • Hi Ravi_Mudaliyar

    Did you change the .net framework to .net 4.7.1 at WCF Service Project?

    If you create a new simple WCF Service with .net 4.7.1, and new console client which call WCF Service under .net 4.7.1, will it throw the same exception?

    Best Regards,

    Tao Zhou


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Wednesday, January 10, 2018 2:16 AM
  • Hi Tao,

    The new WCF service and client works just fine. It looks like something wrong with my existing service/client and I am not able to figure it out. 

    Thanks,

    Ravi

    Wednesday, January 10, 2018 6:56 PM
  • Hi Ravi,

    >>The new WCF service and client works just fine.

    To check whether it is related with the client or WCF Service, I suggest you create a new Console app to call original WCF Service, and Call the new WCF Service from the original Console app, will one of them fail?

    After you upgrade the WCF Service, have you update the WCF client reference? If not, I suggest you update the WCF Service Reference and try again.

    Best Regards,

    Tao Zhou


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Thursday, January 11, 2018 2:13 AM
  • Hello Tao,

    Thank you for the debugging approach. I created a console application(.net 4.7.1) and it is able to connect to the service and getting the expected result.

    As my service is called from ASP.NET website so I thought it is worth checking with a new simple ASP.NET website(.net 4.7.1, ASP.NET Version:4.7.2558.0) and it is failed with the same error which I mentioned in my first post.  The app.config(console app) and web.config(web app) have the same binding setting to connect to the service. I don't understand why it is working in console application but not in the web app. 

    Please let me know how can I make sure that the client and service are using the same protocol/algorithm.

    


    Friday, January 12, 2018 11:39 PM
  • Hi Ravi,

    >> The new WCF service and client works just fine

    Do you mean the working client is Console App?

    If a new Asp.net Client to call a new WCF Service, will it work?

    What is the version for Application Pool to run the Asp.net application? Is it v4.0 .NET CLR Version?

    Do you create certificate for Asp.net Application? I suggest you check whether it is sha512 hash.

    In addition, I suggest you check whether link below could be help.

    #0x80090331 The client and server cannot communicate, because they do not possess a common algorithm

    https://social.technet.microsoft.com/Forums/windows/en-US/bcc6be0b-0385-4aff-82ae-b6e973fe398d/0x80090331-the-client-and-server-cannot-communicate-because-they-do-not-possess-a-common-algorithm?forum=winserver8gen

    Best Regards,

    Tao Zhou


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.


    Monday, January 15, 2018 5:27 AM
  • Hi Ravi, any update on this issue? I am facing exactly same problem. My client app could not connect to my WCF service after enabling TLS 1.2 and disabling all other protocols. 

    I explicitly added 

    System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12;

    It is failing at "(proxy as ICommunicationObject).Open();"

    Friday, January 4, 2019 3:16 PM
  • Fixed the issue after having:

    Client Side:

    b.Security.Message.EstablishSecurityContext = false; b.Security.Message.NegotiateServiceCredential = false;

    Server side: 

    <message clientCredentialType="Certificate" establishSecurityContext="false" negotiateServiceCredential="false"/>
    

    as mentioned in 

    https://blogs.msdn.microsoft.com/dsnotes/2017/04/13/wcf-message-security-limitation-with-tls-1-2-protocol/ 
    
     
    Friday, January 4, 2019 8:07 PM