Welcome to our community!

OnPrem Signing Certificate

Avatar
Andrew Aldridge
  • updated
  • Open

I'm trying to start a thread for us to discuss the latest bombshell that we have 6 days to provide our own code signing certificates, my previous attempt is "Awaiting Moderation" which may just be because I included a URL in the post?

While it feels very much like a final attempt to kill off the on-prem user base, there's no real benefit discussing that other than venting so I'm looking to see if anyone's research so far as turned up an affordable way of acquiring code signing certificates.

The likes of DigiCert, SSL etc seem to come out at several hundred $/year in the first year, possibly dropping from there once you own a suitable storage method for the certificate.

Azure Trusted Signing looked promising for a while at a few $ a month - but is currently only available to USA and Canada based businesses, so rules out the rest of us.

Does anyone have any other sources?

Thanks
Andrew

Replies 81
Avatar
3
omnichad

Even with the information given so far, I literally don't know what to do. I want to spend as little as possible knowing I may be looking for alternatives, so no 3 year certificate. 


I'm a sole proprietor with no employees. I cannot tell from anywhere whether I can even get a compatible certificate. Would I be able to use my business name or do I have to use my first and last name as the legal entity?  

This is ignoring the complexity of setting up azure, which I don't think has any requirements. No clue why their add-on can't just support a physical hardware key (ignoring the time it takes to get here). 


It sounds like it has to be Digicert regardless of reseller and can be either OV or EV but I'm not sure of even that.

Avatar
0
amccabe Team Member
Quote from MTHT

For those considering staying with ScreenConnect, you might want to speak with your security auditors as ours has strongly recommending we move to another platform. 

They stated "If ScreenConnect can sign using your certificate, what prevents them, or an attacker that is able to compromise their software, from signing anything they want using your certificate."

We have already spoken to other providers and to clients who host their own instances and will not be renewing with ScreenConnect and are establishing a plan to being migrating our instance and client instances to a new platform within the next 30 days.

We know this day would come after the purchase of ScreenConnect but didn't expect it to come in this fashion or with this short of a timeline.

Good luck to all those who remain!

Your certificate is never sent to any ConnectWise servers or anything; it's just stored in the web.config.


(This is in the context of on-premise, of course; for a cloud instance, it would be sent to a ConnectWise server, because that's where your web.config is, but using your own cert isn't necessary in the first place.)


I suppose it's possible for an update to add functionality to call out to a server to grab files to sign and send them back; but in the same way, it's possible for an update to, say, change the host client to deploy ransomware when downloaded. There is an additional risk there, yes, but it's a slight addition to a very slight risk.

You can also create a certificate just for use with ScreenConnect, so even if it is compromised, it won't affect any of your other certificates.

And depending on your situation, you could potentially just use the default self-signed certificate (auto-generated on upgrade/install). That isn't trusted by anyone else, so it's quite limited in its usefulness, but if you're only downloading clients on computers you control, for example, maybe that's all you need.

Avatar
2
Nathan Oldfield
Quote from omnichad

Even with the information given so far, I literally don't know what to do. I want to spend as little as possible knowing I may be looking for alternatives, so no 3 year certificate. 


I'm a sole proprietor with no employees. I cannot tell from anywhere whether I can even get a compatible certificate. Would I be able to use my business name or do I have to use my first and last name as the legal entity?  

This is ignoring the complexity of setting up azure, which I don't think has any requirements. No clue why their add-on can't just support a physical hardware key (ignoring the time it takes to get here). 


It sounds like it has to be Digicert regardless of reseller and can be either OV or EV but I'm not sure of even that.

yeah, for someone that's not dealt with code signing certs before (just run of the mill ssl certs) this is something new.  I'm reading conflicting info about the reuqirement for a physical key or if we just need azure key vault premium tier.

Avatar
2
amccabe Team Member
Quote from Andrew Aldridge

Is anyone able to confirm my belief that this code signing has no effect on the Mac or Linux clients, only Windows?

Correct, the code signing only affects the Windows clients

Avatar
1
amccabe Team Member
Quote from stephan

Please provide the possibility of signing a static installer which already includes customizations like the relay server url but don't add session specific tokens or cryptographic material. This would give us the chance to sign the client with a certificate residing in an physical HSM module.

I don't mind when all of our customers would download the same client and have to enter the session code after the client gets executed. This would eliminate the nescessity of having the signature process running for each session.

You should be able to build an installer, sign it yourself, and then run it on as many machines as you want; it'll generate a different session ID on each different machine.

Avatar
3
MTHT
Quote from amccabe

Your certificate is never sent to any ConnectWise servers or anything; it's just stored in the web.config.


(This is in the context of on-premise, of course; for a cloud instance, it would be sent to a ConnectWise server, because that's where your web.config is, but using your own cert isn't necessary in the first place.)


I suppose it's possible for an update to add functionality to call out to a server to grab files to sign and send them back; but in the same way, it's possible for an update to, say, change the host client to deploy ransomware when downloaded. There is an additional risk there, yes, but it's a slight addition to a very slight risk.

You can also create a certificate just for use with ScreenConnect, so even if it is compromised, it won't affect any of your other certificates.

And depending on your situation, you could potentially just use the default self-signed certificate (auto-generated on upgrade/install). That isn't trusted by anyone else, so it's quite limited in its usefulness, but if you're only downloading clients on computers you control, for example, maybe that's all you need.

You still clearly don't understand the concern. YOU built the signing module, which is installed locally, and have not release the code so how can I verify what or how is being signed or stored within that signed package? Where the certificate is stored is irrelevant when you still control the method for signing. What is to prevent a bad actor, either a ConnectWise staff or 3rd party, from pushing a update to the signing module and having it sign a malicious package. 

Sure, you can say what is to prevent someone changing the host client to deploy ransomware when downloaded but again if its signed by ConnectWise then that issue fall on YOU to ensure that does not happen by securing your product. If I am signing then that issue falls on ME and my reputation and code signing certificate are at risk. And again I have no ability to audit YOUR code or the process.

If you want people to put their business at risk then you need to provide the code so that it can be independently verified. Otherwise your just asking for blind trust which has been lost after the last few issues.

Avatar
3
Andrew Aldridge

Yes this - this was misunderstood by the team in the town hall meeting too. You are applying our certificate to code we have no control of.

If there was a supply chain attack on you and compromised clients get pushed to us, our names are all over them when they get deployed.

Avatar
0
stephan
Quote from amccabe

You should be able to build an installer, sign it yourself, and then run it on as many machines as you want; it'll generate a different session ID on each different machine.

But for ad-hoc support sessions I cannot ask every client to install a software. It should be simply downloading a single *.exe file, run it and enter the session code.


I agree it would be a solutions for access sessions. But I am talking about support sessions :)

Avatar
2
Andrew Saucci

I have come to the conclusion that code signing is pretty much useless and may as well be abandoned. Combine that with the looming 45-day expiration on SSL web certificates in general and I'm about ready to give up on those as well. We may as well admit that Internet is not safe and never will be safe-- period. You can't turn the world on a dime. No matter what protection scheme is developed, it seems as though someone will find a way to beat it, and then the rug is pulled out from underneath everyone who was relying on it, and then the endless merry-go-round gets another spin.

Just give us a signed installer without customizations, and get rid of the ZIP file downloads and the annoying Captchas on this web page.

Avatar
1
Brad Hunt

So a dumb question here, what happens if we do NOT upgrade to this new version with the new cert requirements?  Our current version (with customizations) will work but it will just show as unsigned and unsecure?



Top contributors
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar