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: I've done some pretty extensive testing to ensure I've covered all my bases. 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. 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. However, if I re-enable TLS 1.0 by setting 'Enabled' to '1' at this location, everything is fine. 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. If the checkbox for 'Is a local server' is checked, it works fine locally.įor 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. This means the local client is affected also, if you have your connection set up as if it was a remote system. 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. 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. 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.
We're also going through the same PCI audit stuff where I work.
0 kommentar(er)
