• Replies 10 replies
  • Subscribers 338 subscribers
  • Views 154 views
  • Users 0 members are here
Related

Application Server on Windows 2016

John Callinan
$organization

Related to my earlier question, has anyone installed the Tessitura Service, Services Dashboard on a Windows 2016 box?  Is there something I'm missing with TLS?  When I go to Services Dashboard, the probes for Tessitura Service all fail.  Now if I use the Rest Client on the Tessitura Service site I get an error of "The underlying connection was closed: An unexpected error occurred on a send." but if I use the REST client with Firefox I can successfully connect and get data back.  Further, if I point the first Probe_Id at another test environment I get a connection (even if that other server is 2016), but pointing at itself, it fails.  I've even moved the cert to a different server and that was fine.  Really confused?  Thanks.

  • $organization

    I've been running the app server on 2016 for almost 2 years and I don't recall any issues with connectivity.  

    How are you attempting to browse the Services Dashboard?  Are you using SSL connection with valid cert?  

    Todd T

  • $organization
    Yep.  A GoDaddy wildcard cert, that I put on another application server (that is Windows 2012) and had no problems with it.  What really get’s me is the Firefox Rest Client succeeds, but the Tessitura Service Rest client fails?
     
     
     
  • $organization
    Todd,
     
    Did you ever see an error like this when you went to 2016 for the application server?
     

    Failed to connect to Uri - ganon.rpac.org/.../status. Response: System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags) at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size) --- End of inner exception stack trace --- at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size) at System.Net.FixedSizeReader.ReadPacket(Byte[] buffer, Int32 offset, Int32 count) at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, 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.ConnectStream.WriteHeaders(Boolean async) --- End of inner exception stack trace --- at System.Net.HttpWebRequest.GetResponse() at Tessitura.Diagnostics.Probes.DefaultProbes.VersionProbe.Analyse(NameValueCollection appSettings)
     
     
  • $organization in reply to John Callinan

    John,

    I have experienced similar errors in the past.  

    Any firewalls in between client & server?  Is the windows firewall active on the 2016 server?  If so, have you tried testing with it off?

  • $organization

    Hi John,

    That error certainly sounds like a TLS thing.  We had a hell of a time with it a while back, and if I remember correctly it was a RAMP upgrade that set our API servers to not accept old TLS versions.  Since we were on RAMP all of the Tessitura stuff was fine, but a locally hosted web app server was failing.  Finding the configuration settings in the registry to get our servers (mostly 2012, I believe) to default to the right TLS version for .Net apps was extremely non-trivial.  Firefox would naturally work with the right TLS level, so that also fits the pattern.  I can't remember if I hacked this problem out on the forums or the developer Slack channel.

    --Gawain

  • $organization in reply to Gawain Lavers

    Slack channel.  I dug up this link:

    https://stackoverflow.com/questions/45382254/update-net-web-service-to-use-tls-1-2/45441341#45441341

    But also you need to find and set this key: SchUseStrongCrypto

  • $organization
    Thanks Gawain.  Still not working, but I’m not sure where to put the ‘System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12’
     
     
  • $organization in reply to John Callinan

    John,

    If you haven't already - review the following reg keys and compare them between the working and non-working servers:

    HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders \SCHANNEL\Protocols

  • $organization
    Thanks Todd, unfortunately, these are our first 2016 servers.  I did see where you had to Enable the TLS 1.2 in that key and did try that as well
     
  • $organization in reply to Todd Tiffany

    Hi

    I've used IISCrypto with some success in the past - https://www.nartac.com/Products/IISCrypto

    Removes the pain of playing with the registry.

    Alan Stratton