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.
The EXE for the ConnectWiseControl.ClientSetup.exe is signed, but the setup.msi it puts in %temp% is not.
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 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).