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
2
Perry Diels

@GMCfourX4: We're in the same boat. Purchased a perpetual license when it was Elsinore and always paid for yearly maintenance, even after it became Connectwise. Regarding current situation we have not been informed as it should; Chat support was very confusing (heard different scenario's) and during the so called ScreenConnect Experience events they ignored the questions they did not want to answer. No response from support via e-mail either (excepted the automated mails that the cases would expire...). 

As you say, we have paid for the ScreenConnect product wit perpetual (lifetime) usage and there's no reason to involve end-customers with license revocation issues.

I've been informed this situation is not legal... but I'm not 'yet' sure how to carry on. For the time being we are testing alternative products from other vendors. Some have even better features onboard, others not, it depends what one exactly needs. But we are not willing to pay for signed certificates ourselves, its expensive and too complicated in our situation. Especially without any help form CW.  

You are right, we should receive a version that works. Especially as we're in paid maintenance until April 2026. 

Avatar
2
GMCfourX4

Does anyone here own a perpetual license? We purchased from Elsinore Technologies before ConnectWise bought them, and now ConnectWise is giving us the runaround. We had a perfectly functional on-prem server until they shut us down (a year and a half ago, give or take), then then gave us a patched version to run and now they've effectively shut us down again with this certificate revocation. We're just trying to find a version we can install that we are allowed to sign ourselves, but so far they won't even give us that information. Does anyone know what to ask for?

Avatar
0
Stephen Bausch

My underlying issue was that I had Screenconnect installed on an old Windows Server.  I had to migrated Screenconnect to a new, current VM.  After doing the migration, the Screenconnect installers signing started to work.    

Avatar
0
Stephen Bausch
Quote from johnpl

Hello,

How did you do that? Did you buy a new certificate, used cert you already have, connected everything via Azure?

We tried adding our own custom certificate, and it crashed the webpage. I had to restart all the ScreenConnect Services just to get things back online. After the restart, the certificate showed up in the "Certificate Signing" section, but when I try to start a one-time session, I just get a runtime error / and nothing happens.

John,   Are you getting a runtime error like...  this?

Server Error in '/' Application.
Unable to find an entry point named 'SignerSignEx3' in DLL 'mssign32'
That is what I am seeing now.  
Avatar
0
NetServicesGroup
Quote from c g

I had the same issue. The certificate was working but I got a 500 internal server error when downloading the support application. The issue was that Windows Defender on the Server put the file C:\Program Files (x86)\ScreenConnect\Bin\ScreenConnect.Client.exe into quarantine since it thought it was malware. 

Additionally I had to whitelist the folder C:\Windows\SystemTemp\ScreenConnect\ where ScreenConnect puts a temporary file when signing the support executable. Then everything finally worked again.

The executables were signed but had no timestamp in the signature. I found out myself that you have to add an entry in the appSettings section of the web.config file with key="CodeSigningTimestampServerUrl" and value="URI_OF_TIMESTAMP_SERVER". Only after this change did the signed executable have a timestamp.

All in all a complete mess and forcing people to take the most expensive way via Azure key vault, since you cannot enter the private key for code signing certificates issued today. Either you have a USB dongle with the private key or you have a HSM certificate, where you don't have the private key at all. A general signing interface would allow a command line tool to be run for singing the executable but the code signing extension does not offer that. Basically you are forced to use Azure key vault.

Is the syntax of the like added to the web.config simply?

<add key="CodeSigningTimestampeServerUrl" value="URI_OF_TIMESTAMP_SERVER" />

Or is the value specific to the certificate provider? I'm using DigiCert


Avatar
1
c g
Quote from johnpl

Hello,

How did you do that? Did you buy a new certificate, used cert you already have, connected everything via Azure?

We tried adding our own custom certificate, and it crashed the webpage. I had to restart all the ScreenConnect Services just to get things back online. After the restart, the certificate showed up in the "Certificate Signing" section, but when I try to start a one-time session, I just get a runtime error / and nothing happens.

I had the same issue. The certificate was working but I got a 500 internal server error when downloading the support application. The issue was that Windows Defender on the Server put the file C:\Program Files (x86)\ScreenConnect\Bin\ScreenConnect.Client.exe into quarantine since it thought it was malware. 

Additionally I had to whitelist the folder C:\Windows\SystemTemp\ScreenConnect\ where ScreenConnect puts a temporary file when signing the support executable. Then everything finally worked again.

The executables were signed but had no timestamp in the signature. I found out myself that you have to add an entry in the appSettings section of the web.config file with key="CodeSigningTimestampServerUrl" and value="URI_OF_TIMESTAMP_SERVER". Only after this change did the signed executable have a timestamp.

All in all a complete mess and forcing people to take the most expensive way via Azure key vault, since you cannot enter the private key for code signing certificates issued today. Either you have a USB dongle with the private key or you have a HSM certificate, where you don't have the private key at all. A general signing interface would allow a command line tool to be run for singing the executable but the code signing extension does not offer that. Basically you are forced to use Azure key vault.

Avatar
0
stephan

> A larger issue here is whether certification authorities are

> qualified and competent to judge the quality of software

that's not their job actually. They ensure that the identity of the signing party has been verified. This gives you the possibility to build some trust based on that identity.

Certificate Authorities are not judging on software quality.

Avatar
2
Andrew Saucci

A larger issue here is whether certification authorities are qualified and competent to judge the quality of software, as opposed simply to attesting to the validity of a particular certificate. The difference between stating that a certificate has already been compromised and stating that it is vulnerable to compromise is significant. In the former case, what is being said is a fact; the latter case is merely one organization's opinion. I suspect that no software today can pass the "is vulnerable" test, which leaves us open to constant upheaval every time another bored researcher starts tinkering in his laboratory. As a matter of public policy, what does not make sense is the notion of leaving the power essentially to disable otherwise working software in the hands of certification authorities, web browser companies, or others who are answerable to no one and may be no more competent than anyone else. This is a subject that should be subject to rigorous debate at the least.

Avatar
0
Nathan Oldfield
Quote from mal

All my sites gone dead.  I didn't think existing sites/endpoints would be affected, only new and reinstalled ones..  Unless SC have done some other trickery?

The certificate used to sign their code is being revoked.  I thought it was another 3 hours away.  Maybe my time conversion was off.  

Windows / defender / endpoint protection etc would be checking for revoked certificates and blocking it.  

Do you have access to a client machine by some other means so you can check the logs?  I assume the event log would have some clues. 

Avatar
0
mal

All my sites gone dead.  I didn't think existing sites/endpoints would be affected, only new and reinstalled ones..  Unless SC have done some other trickery?



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