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.
Welcome to our community!
Pinned replies
Replies 23
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.
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.
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 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).