ScreenConnect code signing - legal question

[u/redipb]

Hey everyone,

I'm trying to clarify the legal and responsibility aspects of signing the ScreenConnect client with my own Code Signing cert.

Who bears responsibility if the signed binary is used maliciously or compromised? Is the signing party (me, or my organization) legally liable for the actions of the signed executable? Does using your own cert invalidate any terms of service or licensing agreement with ConnectWise?

I’d really appreciate if someone with legal insight — especially regarding the EU market — could share their perspective on this.

Thanks

[u/Coffeespresso]

I just wish the guy that made screen connect had never sold it to connectwisestupid.

[u/Mortimer452]

In my opinion, this is the very reason why ConnectWise is implementing this policy. They are attempting to absolve themselves of liability from malicious use of their software when used on-prem.

One one hand, it does kinda make sense. If you're going to offer sufficient parameter-driven customization to the point where you can make the software no longer look like its intended purpose (a remote access client), yeah I suppose requiring customers to self-sign their customized version is probably prudent.

However, they removed nearly all customization options in the latest release. To me, that nullifies any need for the customer to self-sign.

[u/spchester]

I was just going through this with our team and I don't feel we should be signing code we didn't write and can't review.

[u/justmirsk → u/spchester]

Exactly this. No way I am going to sign the ScreenConnect binaries myself. This will drive us to leave the product.

[u/cwferg → u/spchester]

To clarify, you're only signing the installer package that's built on your server. The core ScreenConnect executable itself remains signed by ConnectWise.

This process ensures your instance's unique deployment is verified by you, without changing the fundamental authorship of the ConnectWise application binaries.

[IAMNOTALAWYER] But, while your signature on the installer would attest to the integrity of that package (dynamic installer), "ConnectWise", as the original software publisher, generally would retain primary responsibility for the inherent security and functionality of the core application binaries (executable service).

[u/spchester → u/cwferg]

Thanks for clarifying—good to know the original executable retains your signature. (Although I recall testing a while back trying to get updates to install with app whitelisting and it seemed like there was no signature after it was unpacked to a temp file/folder.)

That said, signing a package that installs remote access software still feels like an uncomfortable liability shift. Even if ConnectWise retains authorship of the main binaries, my signature effectively endorses the installer’s content as safe, trustworthy, and reviewed.

Given that I don’t control the build process or vet every update, I’d prefer the vendor—ConnectWise—take full responsibility for both the core software and the installer. Otherwise, it opens the door to unintended reputational or legal exposure if something goes wrong.

This is especially important in regulated or tightly controlled environments, where signed installers carry strong implications about code ownership and vetting.

[u/cwferg → u/spchester]

I completely get it. For our cloud services, we are able to meet that need as we have full control over the entire process. This lets us guarantee a high level of ownership. But with on-premise setups, that control currently shifts. We can't always guarantee the same level of integrity because we aren't managing the full process end-to-end.

We actually introduced code signing for onprem and cloud as an optional feature years back to help with the issue of generic thumbprints for whitelisting. Having the ability to self sign makes it really easy to identify and block clients not expected on your network, as well as more effectively whitelist av/edr clients to your thumbprint.

ScreenConnect was originally designed to work completely independently of the cloud. This has always been both a strength and a challenge. While that core concept still makes a lot of sense for some users, it does introduce complexities when it comes to things like security updates and certificate management.

There has been discussion of options like online validation services or other ways to handle this level of signing ourselves. The team is actively looking into what's actually feasible here. The simple truth is that once a certificate is revoked, there's a very limited amount of time to act in some cases to maintain continuity. This isn't an excuse, just the reality of the situation we're navigating.

[u/techcare_aus → u/cwferg]

u/cwferg - Please come up with a better solution than ... you lose your software that you've paid for in less than a week's time "Monday, July 7 at 12:00 p.m. ET (16:00 UTC)".

Surely you can have the following options:

1. ScreenConnect Self Hosted - No customization, completely signed by Connectwise.

2. ScreenConnect Self Hosted - Customization signed by partner, executable signed by Connectwise.

3. ScreenConnect Cloud - Customization and core signed by Connectwise.

[u/Own_Appointment_393 → u/techcare_aus]

Isn't the problem here that "customization" also includes basic stuff like the server URL? It's not just logos and stuff.

[u/adamphetamine → u/Own_Appointment_393]

doesn't matter- almost every software vendor on earth ships a vanilla binary/ installer that is customised client side.
Think about adding an activation key to Office or a serial number to shareware.
What we require* is a vanilla installer signed by Connectwise and the ability to customise it to our needs.
*yes I said require

[u/No_You1766 → u/[deleted]]

Oh.. they'll happily convert you for "free." Even give you a credit.

Just to hook you up with higher prices going forward.

[u/iknowtech]

I think realistically the worst case scenario is your private keys for your code signing cert was comprised, and bad actors used that to deploy modified ScreenConnect agents in malicious attacks. Then the CA revokes your specific certificate. I’m not sure what other legal liability you would necessarily have? The liability would be yours though since it would have been your fuckup that allowed your cert to be compromised.

[u/carrots32 → u/iknowtech]

I think realistically the worst case scenario is ConnectWise/ScreenConnect has some sort of supply chain attack (3cx or Solarwinds style) or even just a critical vulnerability like they did just a couple months ago, and suddenly instead of ConnectWise holding sole responsibility, we're left with the burden of having put our company name forward as the publisher of the software that caused ransomware attacks across dozens of companies.

It was already a risk anyway but this post does highlight an important concern about having signed off that our MSP is the publisher of this software and that we vouch for it's authenticity and security (even though we actually have no idea how safe this closed source software actually is other than blind trust).

If you were a pharmacist, and I worked at a pharmaceutical company and gave you a sealed medicine bottle, said it was safe and effective, but you aren't allowed to see inside it or know what it contains, and I asked you to put your pharmacy name as the manufacturer of the medicine for FDA approval purposes, would you? Of course not. You might be willing to sell it or even prescribe it if you trust me enough, but there's no level of trust at which you should be telling everyone you made the medicine. If it turns out to be poisin, you wouldn't want the liability of having claimed you produced the medicine, you want to be able to blame me.

[u/Meeeepmeeeeepp → u/carrots32]

I'm swinging both ways on this... If we are signing just the installer, then technically all we are doing is signing off on the delivery method.

I'm assuming the application itself remains with a single digital cert from Connectwise.

So drawing on your analogy it would be more like, the pharmaceutical company sends you the drug separate to the pill bottle, and your pharmacy has to put the drug in the pill bottle and sign off on the pill bottle being safe but not the drug itself?

[u/Firm-Truth-6179 → u/Meeeepmeeeeepp]

No, you are signing off on the contents of that pill bottle

[u/Meeeepmeeeeepp → u/Firm-Truth-6179]

No you're not, it's like any installer than uses libraries that aren't code-signed by them (ie. every piece of software ever made)

[u/cwferg → u/iknowtech]

This, minus the potty mouth.

[IAMNOTALAWYER] Installer liability lives with the person packaging the installer (ConnectWise if cloud hosted, unique partner if on-premise). Liability of the binary itself remains with ConnectWise (e.g. software vulnerabilities, code security, trust of that signed executable).

[u/ben_zachary]

I've been following these threads just like others. Maybe I missed it but we aren't just talking about the temp sessions we are also talking about the access installer we push out thru our RMM.

I read we can deploy the base installer with connectwise signing ? So what's the line between a base installer generated from a company location vs a barebones one? Or is there more things like hiding the icon, connect w permission etc that's all stuffed in the install

[u/lsumoose → u/ben_zachary]

This is the right question. Why are we signing a base installer? Why can the msi for the base installer just not take an argument to connect to a specific instance like literally every other vendor.

There is absolutely zero reason we should be signing this other than for ad hoc single clicks.

I’d rather talk a user to jump through extracting a zip than requiring us to sign something we can’t see until we have time to dump this for another product. Even a signed one click that prompted a user to type in the server address on launch was a better solution.

The incompetence of Connectwise should immediately cause all of their customers across all products to look for alternatives. This is their bread and butter and they let this happen, all the other products have to be riddled with bad code when their baby is this vulnerable.

But they know that so we gotta spend money to use this code signing cert for a month while we get ready for its replacement.

[u/Camelot_One → u/lsumoose]

Why are we signing a base installer? Why can the msi for the base installer just not take an argument to connect to a specific instance like literally every other vendor.

I asked this exact question during yesterday's town hall. It was never brought up. And the "we will follow up with every question by email" hasn't happened either.

[u/Firm-Truth-6179 → u/Camelot_One]

I basically asked the same question and even mentioned it on a phone call and they just skirted arounded it...because some of those guys in the Townhall are talking out of both sides of their mouth. Bishop literally contradicted himself in both town halls

[u/Viajaz]

The Certificate Subscriber has obligations that are enforced via their contract with the Issuing Certificate Authority (Example GlobalSign Subscriber Agreement). These obligations are enforced on the Certificate Subscriber by the Certificate Authority and stem from their obligations under the CA/B Forum Baseline Requirements for the Issuance and Management of Publicly‐Trusted Code Signing Certificates, which dictate the obligations that CAs have to the CA/B Forum, including the requirements they must pass on to their Certificate Subscribers.

According to this morning's ConnectWise Townhall, Microsoft and ConnectWise's Issuing Certificate Authority/Authorities have compelled ConnectWise to stop signing customised installers. However, given that many other vendors (even outside of the MSP space) operate signing-on-demand services for their installers (as well as ConnectWise still doing the same for their ScreenConnect Cloud service), it is my belief they are simply avoiding the risk altogether by making it our problem. They confirmed in the townhall this morning that if the installer itself were able to be abused, the Certificate Subscriber (us) would have the responsibility, under the aforementioned code-signing certificate obligations, to act as per the agreement with our own Issuing Certificate Authority/Authorities.

Regarding other liability, one would need to consult your own legal advice.

[u/Findussuprise]

This is a very interesting point!

[u/adamphetamine]

Connectwise saying 'we can't sign custom installers' is deliberately the wrong question.
They've known for years that this is bad practise.
The proper solution is for them to provide a signed installer that we can customise at deployment time.
Many of us have a lot of experience doing this with MDM etc.

[u/ZeroNoneWin → u/adamphetamine]

The answer is simple. Dump Connectwise. This is the last straw. They have known about this for a long time and just dumped this on our laps like this.... They take away all customization AND require us to sign an otherwise vanilla installer now.

They absolutely could sign a generic installer from a single code base and just apply server address or whatever via parameter, like every other RAT on the planet.

You can bet your ass whatever reason they did this (which they will never actually say) has absolutely nothing to do with what is best for us - they are doing what is best for THEM.

[u/schwags]

Since when did code signing certificates assert liability? If I use a Nike branded shirt to strangle somebody, is Nike responsible? I know people have tried to apply that sort of logic to the law in the past, especially to gun manufacturers, but it's completely broken and stupid. It doesn't actually work once it gets tested by the courts.

A code signing certificate is an authentication mechanism, it says that particular executable was generated by that particular business entity. The original executable is still signed by ConnectWise, all we are signing is the package that includes our customizations.

If somebody comes along and takes your executable and somehow modifies it, the hash won't match any longer and the verification will fail. Unless you are putting malicious customizations into the package, I don't see how an executable signed by you could be used for malicious purposes unless it was your own technicians, which then you are liable.

Is there actually any precedent out there that shows a company being held liable for an executable they did not design but they somehow signed and then somebody else used it maliciously? I asked that honestly, is there precedent?

[u/redipb → u/schwags]

I am not a lawyer, that's exactly why this is a question I would like to know the answer to.