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'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.
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!
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 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).
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.
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.
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.
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.
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).