Xibo 1.7.8 Windows Client challenges - TLS 1.2?

We have a fresh install of Xibo 1.7.8 on our server: https://foo.bar/xibo
We can log in and manage it fine: redhat 6.8, apache 2.2.15, php 5.3.3

We’ve tried installing the 1.7.8 client on a Win7 enterprise and Win10 enterprise box. It doesn’t seem able to connect outside of the box- nothing is reported in our netstat and the error comes back immediately. The proper server key has been copied from the web page over to the windows player. A valid local file path with good permissions has been specified. Clicking the “display admin” does take us to our server. The workstation and server are both publicly addressed, though on different subnets.
The error is (and thank you for allowing copy of this text :))
The underlying connection was closed: An unexpected error occurred on a send."
TIA for any insight you can provide!!

I’m almost certain we’re having the same issue. From our load balancer, I was seeing:

Sep 1 16:14:20 loadbalancer2 haproxy[75622]: [ip]:50061 [01/Sep/2016:16:14:20.535] [server]_ssl/1: SSL handshake failure
Sep 1 16:14:20 loadbalancer2 haproxy[75622]: [01/Sep/2016:16:14:20.548] [server]_ssl/1: SSL handshake failure

In previous cases that we’ve investigated for this, it’s because the client doesn’t support TLS 1.2 (we only have TLS 1.2 enabled on our server, not 1.1 or 1.0). I confirmed that after enabling TLS 1.0 on this server, the issue has gone away.

This is a pretty big deal, as a lot of places are going TLS 1.2 only to satisfy the PCI-DSS regulations around this.

Xibo Windows Player uses whatever .NET uses, some information about that here: http://stackoverflow.com/questions/4137106/are-there-net-implementation-of-tls-1-2

It looks like if you have framework 4.5 you can turn TLS 1.2 on by default, if you have framework 4.6 then it is already on by default.

As a matter of interest - TLS 1.2 is supported by Xibo for Android provided the Android OS version the device is using supports it. TLS 1.2 should work on most Android v5 devices.

Awesome- thank you so much as I would probably never teased this out! Enabling strong crypto for .NET was all we needed to do. As kloostec mentioned, we’ve tweaked our httpd services to bump up the security. As most browsers are happy with those tweaks it didn’t occur to us to check (or that .NET did it’s own thing).
Specifically, via powershell we did:

set strong cryptography on 64 bit .Net Framework (version 4 and above)

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord

set strong cryptography on 32 bit .Net Framework (version 4 and above)

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord

Fantastic - i’m pleased that worked!!

We’re running the Windows 10 Anniversary Update (1607), which should have .NET 4.6.2. We had to put the same registry key in, otherwise the client failed to connect to our TLS 1.2-only server.

Thanks for the solution!

1 Like

That is interesting and would imply that the later framework doesn’t have it defaulted. Thanks for letting us know.

I’ve added this to the FAQ - mainly so I can find it again in the future!

1 Like

I just wanted to report that I’m running the Windows client on the latest build of .NET on a Windows 10 64-bit machine. When I attempted to connect the player on the client to my production CMS site, I got this message:

The request was aborted: Could not create SSL/TLS secure channel.

I am running TLS v1.2 on my server.

Manually setting the registry key per the above solved the problem. Thanks for the solution to all who posted!