We have recently upgraded from VisualCron 7.6.4 to 8.0.4.

As part of our ongoing PCI compliance we have disabled TLS 1.0 on our server.

Prior to the upgrade VisualCron clients were able to connect to the server which they are now unable to do so. We have confirmed that this is the issue by temporarily enabling TLS 1.0.

Any suggestions would be appreciated.

Kind Regards

Mark

What kind of Task are you talking about? There are a lot of Tasks using SSL/TLS.

---

It is not any tasks it is connecting the VisualCron client application to a VisualCron Server on a different computer.

1. Have you upgraded both Clients and Server?
2. Have you tested uncheck "Is local" on the Server and connect locally to reproduce the problem?

---

Moved topic to 'General problem solving' instead of the FAQ area.

Henrik,

I can confirm this also. We're also going through the same PCI audit stuff where I work. TLS 1.0 and 1.1 are being disabled on all new servers and eventually will be disabled on existing servers once we confirm it can be without affecting applications. The servers we run VisualCron on are previously built and therefore still currently have TLS 1.0 enabled, though our standard for new builds is to disable TLS 1.0 and 1.1 and enable TLS 1.2 for 'Server' connections. Client protocols are not limited. So it appears that the communication between the VisualCron Client and the VisualCron Service, specifically when 'Is a local server' is UNCHECKED, is relying on the TLS 1.0 protocol being enabled. This means the local client is affected also, if you have your connection set up as if it was a remote system. If the checkbox for 'Is a local server' is checked, it works fine locally.

For instance, Below is the typical registry file we would use in our environment to disable weak protocols and enable the ones we support for new Windows servers. I just applied these registry settings on our Q server that I do VisualCron testing with and although locally the visualCron tray client is able to connect (it's yellow, not red), the Actual 8.0.4 VisualCron client is not able to connect.



However, if I re-enable TLS 1.0 by setting 'Enabled' to '1' at this location, everything is fine. This affects all remote clients connecting to a server with TLS 1.0 disabled in the 'server' portion of the protocol and this will be MUCH more common going forward for customers. I've validated local client works fine (version 8.0.4) regardless of TLS 1.0 being enabled/disabled, as long as 'Is a local server' is checked.



Brian

Hi Henrik,

bbusse has described the problem exactly.

To answer your questions;
1) Yes both have been upgraded
2) And yes if you un-check IsLocal on the server the same problem occurs

"Connection failed to 'localhost'. Connection failed with error:
'An existing connection was forcibly closed by the remote host'
Do you want to try reconnecting?

Kind Regards

Mark

Hi Henrik,

When you are having a look can you also keep the API in mind please.

We do have some jobs that use the VC API . . . . to retrieve Task Details from a number of servers.

Whilst we can Check the 'Is a local server' to get the local client going and bypass TLS 1.0, we aren't sure if we can do that with the API ? . . . . and that (API Calls on these boxes from scripts) are also failing . . .

We have moved one of these jobs (running remote) to local, with the same result.

This suggests the API calls to the server from the DLL are also using TLS 1.0 ?

Thanks

Kevin

Thanks all for the feedback - we will investigate and get back to you!

---

Just putting this out there. It's entirely possible that it's not TLS 1.0 specifically, it might be a combination of TLS 1.0 and the Cipher Suite VisualCron uses (or the ones set in the registry). Maybe the Service is using 'X, XX, and XXXX' ciphers (usually several) and none of them are TLS 1.2 ciphers so the clients can't connect.

In our case, we had to re-standardize our cipher suite (also in registry) to ensure the protocols we leave enabled had valid ciphers that clients could use to connect. It may just be TLS 1.0, but wanted to get this out there just in case.

Brian

Does it work better if you enabled FIPS?

http://stackoverflow.com...dows-7/13635742#13635742 

---

Does it work better if you enabled FIPS?

http://stackoverflow.com...dows-7/13635742#13635742 

I can't speak for the OP, but as for us... enabling/requiring FIPS is not going to happen. It's a major environmental change.

What version of .NET is VisualCron compiled with? Is it still 3.5 ? I was reading something today, though i'm not a developer, that was stating that prior to .NET 4.5 there wasn't a TLS 1.2 implementation. So you'd have to compile your app using .NET 4.5 after applying a hotfix. Again, not sure, it's not my area of expertise. And I realize going to 4.5 would begin forcing migration to later OS's for folks (though I don't personally care about users still using Windows XP / 2003 haha). But all supported Microsoft OS's should support it. (Vista/2008 through current)

Brian

What I don't understand is that it worked in version 7 and broke in Version 8?

Is there not a way to revert back to the V7 protocol, perhaps as an option on the server?

Mark

What I don't understand is that it worked in version 7 and broke in Version 8?

Is there not a way to revert back to the V7 protocol, perhaps as an option on the server?

Mark

Ohhhh. That's an interesting bit of info. I hadn't even thought of trying an older version, i figured they were all a problem.

Brian

We will investigate this more. Reverting back to 7 protocol is not an option as it is less secure. We will iget back to you.

---

Can you elaborate on being less secure? With the updated protocol, were there hard-coded Ciphers it's using to encrypt it's communication? If so, they could all be ciphers that are TLS 1.0 compatible and if so, simply adding a few Ciphers that are compatible with TLS 1.2 would suffice.

Brian

Can you elaborate on being less secure? With the updated protocol, were there hard-coded Ciphers it's using to encrypt it's communication? If so, they could all be ciphers that are TLS 1.0 compatible and if so, simply adding a few Ciphers that are compatible with TLS 1.2 would suffice.

Brian

I may have to take that back. We are still investigating. When you say 7 protocol - which version are you referring to then?

---

I've done some testing on my own just regarding the older versions because that was mentioned by the OP in relationship to the VC Protocol 7 maybe working.
I've tried the following versions both with and without TLS 1.0 enabled.

6.2.2
7.2.1
7.5.1
8.0.4

They all exhibit the same behavior. With TLS 1.0 enabled, Client connects fine (when assuming remote server, is local unchecked). Disable TLS 1.0 and the only connection that works is the IPC connection locally (Is Local box checked).

I'm still downloading (slow connection) 7.5.2 and 7.6.0 as there appeared to be some pretty signifigant changes between those versions. 7.6.4 and 7.6.5 appear to work fine with TLS 1.0 Disabled. So somewhere between 7.5.1 and 7.6.4 (I'm assuming 7.6.0) TLS 1.2 became supported and presumably dropped again at 8.0.0+

EDIT: TLS 1.0 being disabled works fine starting with VisualCron Version 7.5.2 (7.5.1 does not work). Downloading 7.7.8 (last version i see before 8.0.0) to see if it works there.

Brian

What operating systems are KJDavie and uqmtho24 using?

My tests are inconsistent on Windows 10 Pro so i'm going to move to testing on 2008 R2 and 2012 R2, where we normally run VC. I was just using a clean Win10 Pro install on a new laptop because it was portable and i could do testing on the side.

Brian

Hi Brian,

We have Windows 7 typically on the Client, but can access Corporate Builds on Windows 10 if required.

We have a mix of 2008 R2 and 2012 Servers.

Testing Yesterday around this issue was to a 2008 R2 Build on the Test Server.

We are wary now also of testing Client Side only (VC Server and VC Client on same PC). We do use it of course for Beta's but try to always use the server for anything but basic checks / task investigation.

Yesterday we had inconsistent results also Client Side / Windows 7 as it is very easy with all the testing to be inadvertently using IPC Local . . . . which was when we deployed the beta to our Test Server and were not able to connect. Also have you found that the Registry toggles (TLS 1.0 off and on) need reboots to be consistent / effective ?

We weren't as comprehensive as you on versions 🙂. We have been toggling between our Old Production Version (7.6.4) , Current Production (8.0.4) and 8.0.5 Beta yesterday.

Regards

K

Ok. I've done some pretty extensive testing to ensure I've covered all my bases. I'm still finishing up my 2012 R2 testing and will know more shortly there, but when using 2008 R2 as both the client and the server I can definitively say the following:

=====================================================
2008 R2 specific testing:

If TLS 1.0 is disabled (Server key, not client) on the server running the VisualCron service as noted in previous posts containing the registry keys used to test, VisualCron Remote clients Version 7.5.1 and older, and 7.6.5 and newer, do NOT work. All of my testing from a client/server perspective was done with matching versions. I only ever tested 7.5.1 against 7.5.1, 7.6.5 against 7.6.5, etc.. FYI

Now, what my findings show and what it means to me is..
7.5.1 doesn't work but 7.5.2 does. What Changed to start having TLS 1.0 not required.
7.6.4 worked fine but 7.6.5 does not (nor any version after). What Changed here to now require TLS 1.0 again?

So between versions 7.5.2 and 7.6.4, you could have TLS 1.0 disabled and everything was fine.

One thing to note. 2008 R2, fully patched, is using the built-in/updated .NET 2.0 that came with the OS as well as .NET 4.0+ that gets added when you run every update from WindowsUpdate. So when I installed VisualCron, I was never prompted to install the .NET 3.5 Features. In 2012, you are prompted, and i assume that's because either the installer or some other bit is still looking for .NET 2.0 (since 2008 doesn't have 3.0 or 3.5 and it didn't prompt for it). Keep that in mind, it might have something to do with my 2012 testing coming in another post real soon.
=====================================================

Now, interestingly enough, regarding 2012 R2. the same scenario with 7.5.1 not working and 7.5.2 working fine is true. However, EVERY version 7.5.2 and newer on my 2012 R2 test machines (also fully patched up to, but not after, installing the .NET 3.5 Features when prompted) works just fine with TLS 1.0 disabled. I tested them all up to and including the latest 8.0.5 beta. They all work. Now, the testing i'm finishing up is the fact that the .NET 3.5 Features were installed but i have not patched any of it. Maybe a later patch that affects .NET 2.0 (previously not on 2012 R2 when fully patched) is the culprit here. I'll edit/update this post shortly.

EDIT: Patching the .NET 3.5 Features on my 2012 R2 servers has had no effect on VisualCron. Any version 7.5.2 or newer when using 2012 as the client and server works fine with TLS 1.0 and 1.1 disabled. Maybe the TLS not working has something to do with requiring .NET 3.0 or 3.5 (whatever is missing in 2008 R2 since it only has 2.0 and 4.0+

I'll do more testing by installing .NET 3.5 on my 2008 R2 test servers and update the post.

Brian

One addition to my previous post. I just realized I hadn't done a 2008 to 2012 or a 2012 to 2008 test. So below is a listing of 2012/2008 testing scenarios.

Tested using 8.0.4 (Prod Release) with TLS 1.0 = disabled

Specifically this registry entry:


================================
Client = 2012 R2
Server = 2012 R2
Result: Connects Fine / Works.
================================
Client = 2008 R2
Server = 2008 R2
Result: Failure to connect
================================
Client = 2008 R2
Server = 2012 R2
Result: Failure to connect
================================
Client = 2012 R2
Server = 2008 R2
Result: Failure to connect
================================

Brian

Can you please test with this build:

https://www.visualcron.c....aspx?g=posts&t=7604 

---