- Revenera Community
- :
- FlexNet Connect
- :
- FlexNet Connect Forum
- :
- FlexNet Connect verification of downloadable exe file Checksum or Digital Signature doesn't work
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
FlexNet Connect verification of downloadable exe file Checksum or Digital Signature doesn't work
Hi,
I'm using FlexNet Connect (https://publisher.flexnetoperations.com/) and defined a Product Update which is an executable file for windows platform.
I tried using the feature "Validate digital signature" but it doesn't seem to work for me.
I have tried both available options "Signed Executable" and "SHA-1 Hash (Hex)", but no matter what value I enter in the "Security signature" textbox, it doesn't validate the actual file when the client\agent is downloading\running it.
A few notes:
- Our executable setup update file is digitally signed with a valid certificate,
I tried putting the public key and the signer name in the "Security signature" textbox.
- I also tried generating a CRC hash based on SHA-1 and putting it in "Security signature" textbox.
None of the above worked.
Do I need to do something else in order for this feature to work (may be activate a flag in the client side or call a specific function, etc.)?
Thanks, Idan.
- Tags:
- digital signature
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
We are using sha1 signatures since years. It works, that means:
when I corrupt a file on the server and download it, FNC-SDK detects that the SHA1 does not match and signals an exception.
When I download the uncorrupted file it works in 99.9%
But we see some
FlxDotNetClient.InvalidSignatureException, message=A service system error was encountered: Signature didn't pass validation. [1,7E0,8,1[7000001E,0,20050307]]
where we do not know where they are coming from. We use https for download, so there should not be a "man-in-the-middle" attack.
I personally never had that issue, but some of our customers have, we see that in anonymous error logs that are uploaded.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
We have a Unit Test for that (we have developed our own FNC client using API of FNC 2017 R3).
It downloads a file and in the definition of a MultiPlatform Update used for this test we have set SHA1 to a wrong value.
During the Unit Test we first check for Updates of the corresponding product and then download this test Update using FNC method INotificationUpdate:DownloadAndExecute, for which we have defined a callback like
private NotificationUpdateStatus DownloadDelegate(NotificationUpdateStage stage, long currentSize, long totalSize, INotificationUpdate update, Exception exc)
which is given to DownloadAndExecute as 3rd parameter.
At the end of the download of the file with the wrong SHA1 this DownloadDelegate gets called by the FNC API with
stage = DownloadFail
exc.Message = "A service system error was encountered: Signature didn't pass validation. [1,7E1,B,0[7000001E,0,200502F7]]"
That's how we detect downloads with wrong signatures in our FNC client.
As I said in my first reply: we wonder that our client really sometimes reports such invalid signatures, although we use https for download. I thought that https is safe and reliable, but it seems not in all cases.
![](/skins/images/D60DF682EA37BF37032955CE10F3F0BB/responsive_peak/images/icon_anonymous_message.png)