Sign setup.msi for Support Client Installation
The EXE for the ConnectWiseControl.ClientSetup.exe is signed, but the setup.msi it puts in %temp% is not.
Answer
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.
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.
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
- h= host / relay server
- p= port
- k= encryption key
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.
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).
Why is this feature Request closed when the suggested answer is not a solution?
The .EXE doesn't call the unsigned, randomly named/hashed file and it is instead claled by MSIEXEC directly making it impossible to securely allow in applocker or equivalent products.
Totally agree. Not resolved and no way to prevent via security software so every update becomes a pain.
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 :-(
Same issue here. The setup.msi file in the temp folder is not signed and so our AV blocks it from running.
Kind of sad to see how 6years later and this is still an issue that has not been fixed.
On-boarding new clients or using support sessions is a nightmare with non-technically inclined end-users.
As mentioned previously, we can sometimes add exclusions when the client is using an MSP endpoint protection or on-prem antivirus where we have previously added an exclusion but for net-new clients or one-of clients it is a nightmare.
Much like the UTC based reports that don't mention they are in UTC and no way to set it to local time.
@Michael Legato These have been around forever and need to be fixed.
This is very disappointing. For the amount of money that you are paid for a product, this is not that complicated of an issue to fix. The fact that this hasn't been resolved after 6 years is very telling about the priority you place on the security of your clients. I'd love for this to be escalated to someone who actually is able to resolve this issue.
We have no way of setting a safe policy in ThreatLocker to permit this update, due to the MSI being unsigned and being called by MSIExec.
Hi All,
I wasn't able to get any specifics or a timeframe for release (as per 1 month ago it was not yet in alpha) however I was advised that Version 23.7 should have a better solution for this issue.
We shall see!
Customer support service by UserEcho
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).