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
1
P K.

Due to the changes introduced by ConnectWise, we were required to purchase our own EV Code Signing Certificate. We have successfully completed the implementation and configuration. The installer signing process is working correctly, and Microsoft SmartScreen properly identifies our company as the verified software publisher. However, the installer is still being flagged as a potentially unsafe file when downloaded from the Internet.

We suspect that this behavior may be related to the absence of a timestamp signature on the generated installer. I previously discussed this with CW support team and was informed that the last version where timestamping was working correctly was 25.9.9.9530.

According to the information provided, timestamping support was removed starting with version 25.9.10.9545, with the expectation that it would be restored in a future update. However, more than six months have passed since then and no update addressing timestamping functionality has been released.


Is there an expected timeline for when timestamp support will be reintroduced? We are currently running the latest available version, 26.4.3.9662, and the installer still does not receive a timestamp signature.

As a result, after downloading the installer from the Internet, users must first manually unblock the file before they can execute it without SmartScreen warnings. This significantly impacts the user experience and partially defeats the purpose of deploying an EV Code Signing Certificate.

Any information regarding the current status of timestamping support and potential workarounds would be greatly appreciated.

Avatar
0
c g
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.

This is no longer working since at least version 26.1.25.9592.

The code has changed and instead of passing the timestamp server URL to the function responsible for getting the timestamp and writing the signature, null is passed and no timestamp request is even made to the timestamp server.

Avatar
0
eNet

First, does anyone know how to get the email field populated? Or is that necessary?  

Second, does anyone have support sessions working such that the client does not get stopped by Smartscreen and/or give the Unknown Publisher errors when trying to connect with someone?


I’ve been asking Connectwise chat support about these questions for three weeks now and the chat support person, each time I have asked for an update, tells me that the problems have each been reported and they will be resolved when development releases updated versions to fix these issues. I replied “Really???? That answer is absolutely no help at all! I wish I could have figured that answer out all by myself! Duh!!!”


Avatar
0
Brent Pirolli
Quote from NetServicesGroup

@Brent Pirolli How did you get the e-mail address and time stamp working?

I posted 24 hours ago but it's still left "on moderation" apparently as Connectwise runs this forum about as well as their software updates... I had a link in the post to some documentation that apparently flagged the post. Here's the rest of it:

Total newbie here to Code signing... I am not seeing a timestamp on my signatures either. I am signed properly with my Digicert via Azure Key Vault... I tried editing the web.config and just after the line with:
<add key="CodeSigningProviderType" value="AzureKeyVault" />

I added:

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

...and that did nothing.

Then I realized that was a placeholder you used and I have to put in the actual URI of my cert provider's timestamp server:
<add key="CodeSigningTimestampServerUrl" value="http://timestamp.digicert.com" />

That works!

Edit: Email still shows as "Not Available" but there may be some key/value that would populate that if you need.

Avatar
0
NetServicesGroup
Quote from Brent Pirolli

We have our Azure Key Vault working, digicert code signing cert in there, plugin installed for azure certificates in SC... installers are signed and timestamped... but STILL can't push re-install or auto-updates to PC users. EXE downloads fail... MSI work. Remote support sessions with clickonce launcher throw a server application error... this is a hot mess.

@Brent Pirolli How did you get the e-mail address and time stamp working?

Avatar
1
Brent Pirolli

We have our Azure Key Vault working, digicert code signing cert in there, plugin installed for azure certificates in SC... installers are signed and timestamped... but STILL can't push re-install or auto-updates to PC users. EXE downloads fail... MSI work. Remote support sessions with clickonce launcher throw a server application error... this is a hot mess.

Avatar
0
GMCfourX4
Quote from mal

Hi GMCfourX4, you want a key or the installer?

We're just trying to get an installer that we can sign, and we're getting the run around from ConnectWise, even though it's a problem as a direct result of actions they took. So frustrating.

Avatar
0
mal
Quote from 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?

Hi GMCfourX4, you want a key or the installer?

Avatar
1
Perry Diels

@GMCfourX4

I agree with you... the software is running on the same supported OS and nothing has changed, hence there's no reason for the software to stop working. When we have acquired the software what do we know if third party components are necessary or even included under the hood. As you make a comparison with a car, I can add to that that we don't have anything to do with 3rd party components. For example: At this moment there are problems with airbags with certain car brands (no need to mention them here) ... but the customers don't have to contact the concerned airbag manufacturers for a solution, or pay themselves for a good one from another brand. They have a deal (and warranty) with the car brand and it's the latter that has to take responsibility. Same if we sell a self-assembled PC-system to a customer... if it stops working, we're going to find a solution without saying that it is out of our scope, because a 3rd party component stops working!

@Wardrop I feel you have a certain sympathy for ConnectWise. I agree with the part that ConnectWise has (most likely) not deliberately made this choice - I'll leave that open - but it's their responsibility to make sure that their application keeps working as to what customers have paid for. As long as this is running on a supported system (OS ...), that is.


I don't believe in the conspiracy theory either, but you are correct that it's a lack of proactivity and incompetency. They may have had many support cases when this came up, but even now after +3 weeks there's still no response from them; No solutions or any further helpful info... I don' see any excuse here.

Avatar
0
Wardrop

I can't say I agree. The certificate was revoked by a certificate authority which is a 3rd party. This isn't something ConnectWise have orchestrated in the sense of planned obsolescence. There'd be more effective ways to do that if that was their intent, and it would likely start with them no longer selling a perpetual license which they still do by the way.

It's the result of perhaps poor software architecture decisions and a lack of proactivity. It reflects badly on ConnectWise as it should, but it's more a result of incompetance rather than any kind of conspiracy forcing users to the cloud.