FlexNet Connect verification of downloadable exe file Checksum or Digital Signature doesn't work

[idan37s]

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.

[gschmitt]

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.

[idan37s]

Hi, Do you know which function is throwing the exception? I entered a wrong hash and haven't got any indication of the invalid signature.

[gschmitt]

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.