After moving from HTTP to HTTPS - no Site Server Task Servers are able to register
search cancel

After moving from HTTP to HTTPS - no Site Server Task Servers are able to register

book

Article ID: 195963

calendar_today

Updated On:

Products

IT Management Suite Task Server

Issue/Introduction

The customer reported some issues with one of his Site Servers (SS), where the Task Server (TS) on the Site Server (SS) is not able to register to itself after they moved from HTTP to HTTPS connection.

The SMP and SS have TLS 1.0 disabled (1.1/1.2 enabled). In All Agent and Site Server communication profiles, TLS 1.0 is unchecked.

Task Server on SMP is able to register and working.

TS on SS not able to register.

The following entry van be seen in the agent logs on that SS:

"NotificationServerWebConnection.PostToNotificationServer()

The underlying connection was closed: An unexpected error occurred on a receive.

   [System.Net.WebException @ System]

   at System.Net.HttpWebRequest.GetResponse()

   at Altiris.DotNetLib.Helpers.AtrsHttpOps.Execute[T](Func`2 action, String url, ICredentials credentials, Boolean isPost, Int32 timeout)

   at Altiris.ClientTask.Server.Communication.NotificationServerWebConnection.PostToNotificationServer(String url, ICredentials nsCredentials, NSWebConnectionBuildRequestStreamDelegate requestStreamDelegate, Int32 nMaxAttempts, Int32 nTimeout)

 

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

   [System.ComponentModel.Win32Exception @ System]

   at System.Net.SSPIWrapper.AcquireCredentialsHandle(SSPIInterface SecModule, String package, CredentialUse intent, SecureCredential scc)

   at System.Net.Security.SecureChannel.AcquireCredentialsHandle(CredentialUse credUsage, SecureCredential& secureCredential)

   at System.Net.Security.SecureChannel.AcquireClientCredentials(Byte[]& thumbPrint)

   at System.Net.Security.SecureChannel.GenerateToken(Byte[] input, Int32 offset, Int32 count, Byte[]& output)

   at System.Net.Security.SecureChannel.NextMessage(Byte[] incoming, Int32 offset, Int32 count)

   at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)

   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)

   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)

   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)

   at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)

   at System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size)

   at System.Net.PooledStream.Write(Byte[] buffer, Int32 offset, Int32 size)

   at System.Net.ConnectStream.WriteHeaders(Boolean async)

 

While doing Wireshark - we can see that all requests are done on TLSv1.2 protocol.  When restarting AtrsHost service on the SS - no TLS requests are made.

When we Enable TLS 1.0 on all platforms - everything is working. Even if we "do not use it"

 

System Event Log - on SMP from SS(remote event)

Error SCHANNEL Event 36888

TLS fatal code 10, SChannel error 1203

Environment

ITMS 8.1, 8.5

Cause

TLS misconfiguration. In order to enable TLS 1.2, please refer to Microsoft documentation:
https://docs.microsoft.com/en-us/dotnet/framework/network-programming/tls

If the SystemDefaultTlsVersions=1 then communication protocol is chosen by OS, but if the value is 0 then communication protocol is chosen by .NET Framework. By default the setting has the value SystemDefaultTlsVersions=1 on .NET Framework version since 4.7 and has the value SystemDefaultTlsVersions=1 for other versions of  .NET Framework version.

You need to make sure "SystemDefaultTlsVersions=1" is used on Site Server side. The problem is gone after the AtrsHost service restart.

Resolution

We suggest to configure SChannel to default state with switched off TLS 1.0 on SMP and Site Servers (Note: Make a backup of SChannel settings):
 
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
"EventLogging"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\CipherSuites]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client]
"DisabledByDefault"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]
"Enabled"=dword:00000000
"DisabledByDefault"=dword:00000001

 

Apply the registry fix from the Microsoft article mentioned above and set SystemDefaultTlsVersions=1 on Site Server side. The problem should not be reproducible after server restart.

Please also refer to the following KBs:

172933 "New client machines can't register when only TLS 1.2 is enabled on the SMP server. COM error: An existing connection was forcibly closed by the remote host (0x80072746)"

172653 "Unable to register to a Task Server if only TLS 1.2 is enabled"

162386 "The client and server cannot communicate. TLS version mismatch"