The EXE for the ConnectWiseControl.ClientSetup.exe is signed, but the setup.msi it puts in %temp% is not.
I'm sorry for the delay on this response! When the Control agent auto-updates itself (or when someone issues the Reinstall command), we use the signed .exe version of the client installer, and it is sent to this folder on the Guest:C:\Windows\Temp\ScreenConnect\<version>\ScreenConnect.ClientSetup.exe
The exe file then extracts/runs the unsigned msi from the Temp folder. If you are able to whitelist the developer cert that's used on the .exe to allow it to then run the msi, then that should help alleviate the Zero Trust issue with regular upgrades (and also would help with the file hash issue you mentioned, since the file hash changes every time the installer .exe is created).
This is all necessary to happen in the current iteration of the Guest client because the installer can be customized with different values, e.g. the Name, Company, Site, etc. information (CustomPropertyN values).
We have this problem as well. We use on-premise ConnectWise Control 6.5. When a user downloads the session-specific client installer, they get a security warning in Windows because the installer is not signed. Teaching our end users to ignore security warnings is not acceptable.
This is how the feature should work: In the Admin panel, under Security, in addition to Users and Roles, there should be a Code Signing section.
The code signing section should have textareas to paste your Authenticode certificate and private key (PEM format), a text input box to specify a timestamping service, and a checkbox to enable signing of client installers.
This should be doable whether the host is linux or Windows. The code signing tools are included in both .NET and the Windows SDK.
Any news for this?
Would like to know this too.
Any news, please?
Still now news? We have still the problems with deploying the clients to our Windows 10 installations, because we have Adblocker enabled
This is causing a lot of grief for our teams at the moment. I was told it's not possible to sign the MSI's because they are being changed on the fly. But since the .EXE contains the MSI isn't the .EXE also being changed on the fly?
Automate's MSI's are signed and are custom per site.
Yes. A signature would definitely make life easier for us too!
Please, fix this problem. It's a pain to deploy without a signed msi install package. I agree with Matthew Mellon, "teaching our end users to ignore security warnings is not acceptable."
Best practice has become to block executable content from user location such as %temp% in order to prevent drive-by downloads that lead to ransomware. Being able to create certificate-based exceptions for core applications helps to ease user pain around this policy.
The inability to do so for ConnectWise Control means that we can't use the product that we are paying for.
Alternatively, please provide a supported base installation via GPO that supports updates. An example that comes to mind is Pulse Secure Connect, which allows us to push a Windows installer service that can then install and update the remaining components.
Not perfect, but here's what I've done for the client setup (technicians)
1.) download the client setup (recording the URL used) - under downloads in chrome or edge.
2.) Make sure you keep the following and discard the other info in the URL
3.) redownload the client setup using the newly created URL below.
4.) deploy exe via GPO or other 3rd party platform.
We also have been in talks with ConnectWise re install and update. If file is not signed or known by http://virustotal.com then it does not run.
We've had this issue too with Control recently and its causing major grief for a few key clients of ours.Can we please make it so that the installer is signed, even if just by my Control server, so that I can then whitelist my certificate?I understand its difficult to get ConnectWise themselves to sign it, but you should at least be able to sign it using my own certificate.
We have an issue with our Zero Trust whitelisting application that blocks control upgrades every month. This should really be signed so that we can create a specific rule to help the system identify it as ok and allowed.The other issue is that the .msi file name and hash changes all the time as well making there nothing specifically identifiable that this is from ConnectWise control to allow or whitelist.
We are using the AppLocker from Microsoft - we have whitelisted the Cert from the "ScreenConnect.ClientSetup.exe" - but this doesn't solve the problem, because the msi in the temp folder will be still blocked. So without any local Adminrights, it's not possibile to run the client :-(
Customer support service by UserEcho