OnPrem Signing Certificate

Avatar
  • 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

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
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
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
1
Nathan Oldfield

ummm...  what email did you get?  I have not seen anything about this, running SC on prem.  what was the subject?  I'll go hunting for it.

Thanks

Avatar
0
stephan
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!

that's actually a good point. Moving EV code certificates to HSM modules has been done in order to reduce the risk of misusage. An online available support platform being able to sign arbitrary files (on the fly) is an awkward security situation.

Again I think session specific settings should not be included in the signed client but supplied by the user after executing the client application (as many other vendors of remote support software are doing as well).

Avatar
2
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!

Avatar
0
Andrew Aldridge

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

Avatar
1
stephan

> Now that this customization is no longer possible, it creates a real
> operational issue for MSPs like us—especially in environments with
> strict security policies.

maybe you can validate against your own code signing signature. Would be the better approach and more secure then just relying on naming conventions.

Avatar
1
romain jamin

Hi everyone,


I’d like to raise another important point related to this change: the removal of the option to customize the name of the generated executable.

Until now, we used this feature to define specific antivirus/EDR exclusions for our clients. It was a simple and effective way to avoid false positives while maintaining control over deployments.

Now that this customization is no longer possible, it creates a real operational issue for MSPs like us—especially in environments with strict security policies.

Has anyone found a workaround or an alternative approach to deal with this new limitation?

Thanks in advance for your feedback.

Avatar
3
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.