"does not match actual sha1".... but it should

Content Authoring
1

My desktop team is starting to get sha1 errors on there test server and it really doesn’t makes sense. They are coding there package to the proper sha1, but when the root tries to cache the package, it checks the sha1 and it comes up with something else.

RD page shows:

Action: 18854 Retry Mirror Request
url 1: http://server.domain.com/SoftwareRepository/package.zip
Error Status: Error downloading {aid=18854,index=1,sha1=686e785ebcd39873f47b65e342db78f00a09a089,size=null,url=http%3a%2f%2fserver.domain.com%2fSoftwareRepository%2fpackage.zip}: Error processing completed download: Requested sha1 686e785ebcd39873f47b65e342db78f00a09a089 does not match actual sha1 19567f5cb7c07a71e925a0c0b3b3fcabeb39d319

I can wget the file from the root and sha1sum it, I get the expected sha1. There’s no proxy in place and I don’t think it’s behind an F5 or something. That said, I would expect the wget would come back with the same sha1 the root is getting.

1 Like
2

these issues are not fun to dig through. I would try to get the sha1 value of every hop along the way - check it on the root server, check it on the relay server, check it on the endpoint. See if you can spot where it’s not matching any longer. That will give you a better idea of what to troubleshoot or where it might be getting modified along the way.

1 Like
3

First place I’d check is on the root server’s sha1 directory itself. If there is a partial file, failed download, manually-cached file that’s named for the right sha1 but content has the wrong sha1 value you might get something like that. I have a dim recollection we may have done that to ourselves once manually-caching the wrong JRE file.

1 Like
4

It’s happening on the root server. I tried looking in the download and sha1 dir and couldn’t find the files. I hit retry and it appears things have cleared themselves out. Next time I’ll check those directories first. We were having this issue from time to time before, but we had a mucked up server and we new it. I just rebuilt it and moved all the clients over to the new masthead and some of the issues we have seen have gone away. That team just ignored this one because they knew things were wrong. I’m somewhat suspecting there processing and timing that’s causing this problem.

Thanks guys!

1 Like
5

There could be some access problem with the root server hitting that location because its blocked? The SHA could be a hash of an error page for example so there are a lot of things that could be happening.

When you tried to wget the file did you do it from the same machine that the root server is on?

6

Yes, I did it from the root server.

7

I think we figured it out. Files are on a NAS, but that’s mounted on a windows server and dished out via IIS. I think IIS is caching the file. I talked to the packagers and they said it happens when they change the package and update the sha1. So the package name stays the same. Important details to know!

1 Like
8

Similar things happen to vendors that keep changing the same URL with “new” revisions (Acrobat and Java come to mind) so its definitely a common problem

9

That was probably it. It probably would have worked if the pkg name was changed each time.

I’d bet it got cleared out because the IIS cache expired.

10

I had a similar issue with a very weird cause:

I was using a proxy server that decided (out of the blue) to add header to every packet coming through, so eventually the HASH didn’t match.

Changing the proxy solved the issue.

11

Same issue here…I am doing PhishMe Reporter plugin deployment using the newly built Bigfix Server. This is the error I got:

Download error: "Error processing completed download: Requested sha1 248304e6af9ec754d75daa3ef8a11b361e89d8df does not match actual sha1 5e5cc82be0ac133cce57a72754a232a5876e7e20"
Download requested on server:
URL: SWDProtocol://127.0.0.1:52311/Uploads/248304E6AF9EC754D75DAA3EF8A11B361E89D8DF/PhishMe%20Reporter%203.1.3.msi.bfswd
Hash: (sha1)248304e6af9ec754d75daa3ef8a11b361e89d8df

Please advise.

Thanks.
-Mike

12

You might want to also verify that you don’t have Anti-Virus software scanning the content you upload/download. If it modifies the content in any way, it will impact you SHA1 values.

13

Checked the AntiVirus and we don’t see any scanning logs related to upload/download activity.
Just to let you know that this is a newly built Bigfix server with Bigfix version 9.5 installed and being done by our Vendor. It seems to me there might be lacking configuration or perhaps missing tools/plugins as pre-requisites?