If you get the sha256 from the same place you got the main file, then anyone tampering with the main file could also recalculate the sha256 to match the tampered file. A signature signed with a certificate uses complex math (public-key asymmetric cryptography) to give some certainty that the signed content (the sha256) is the same sha256 that the original file author created. It’s not mathematically feasible to recalculate the certificate signature. Why don’t we just sign the whole original file with the public-key crypto and skip the sha256? Because asymmetric crypto is much, much slower than plain symmetric crypto or hash functions. It’s faster and easier to generate the valid hash or key, then sign or encrypt just the smaller key.

@hedge doing the math is one thing. Deciding on the semantics of what it MEANS is something else. If it verifies, what does that mean? Does it mean the contents of a file are “good” (valid, trustworthy, not malicious, complete, etc)? Does it mean you know WHO signed it? And what does that WHO really mean? A person, an organisation? Was the user that caused the signature authorised to do so? What do you believe about the identity, knowing that the certificate validated?

And if the certificate DOESNT verify…what does it mean? Does it mean the contents were modified? Does it mean the contents are invalid? And HOW does it fail to verify? Was the signature made before the NotBefore date? Was the signature made after the NotAfter Date? Is the certificate fine and the signature valid, but the certificate who signed the certificate who made the signature somehow untrustworthy? Or maybe the certificate you have is a tampered certificate where the identity has been modified, but the cryptographic math of the signature on your file checks out. So the contents of the file are probably fine.

We don’t ask these questions. And we definitely don’t answer them. As James Mickens says in his talk about computer science, “The stuff is what the stuff is, man.”

What are you trying to do? If this is SAML or some sort of signed auth, yeah it’s kinda really important to verify that. If it’s data that you’re ingesting, yeah you probably want to know who it came from. Otherwise anybody can send you junk data and overwrite your customer data (or whatever you’re importing). If it’s some binary blob you’re running, yeah you should probably verify that signature is signed by somebody you trust.

Depends on the context, I think. For me, I rarely do it for personal stuff. If I wanted to be perfect, I could do it, assuming a signature is available to verify, but I’m lazy. I would venture to say most folks don’t do it either.

With that being said, where I have been consistent about doing it has been writing config management code at work. If I need to have it download an installer from an untrusted source, I can verify that I’m installing the same package on all servers by verifying the signature before installation. This doesn’t always work well in all circumstances, though.

EDIT: thanks to all who replied. Maybe I should have written “what’s the easiest way to verify an apk file on an android phone?” Unfortunately, I guess I’m not smart enough to understand your answers 🙁