What is the difference between a certificate, a signature and a thumbprint in case of windows exe/binaries?

What is a signature certificate?

Digital Signature Certificate (DSC) is affixed on documents submitted in electronic form by the authorised person. It ensures the security and authenticity of the documents submitted electronically. DSC is affixed on all the documents filed on the Ministry of Corporate Affairs (MCA) portal. Online transactions such as Incorporation of company or LLP, Income Tax e-filing is validated using DSC.

This is long. There's an example at the bottom that may help.

A Signature is a bit of cryptographic wizardry where you take some smallish piece of data - almost always the cryptographic hash (something like SHA256) digest of a message, file, or other data blob - and then perform an operation on it (called signing) with a private key. Since only you should ever have access to your private key, only you can produce that exact signature on that data. However, anybody with your public key can verify that signature - that is, confirm that it was made with your private key - and since they have to hash the message/file/blob again to get the digest as it was before being signed, they can tell if the message was modified, too.

In the context of binaries, the process goes like this. Somebody (let's say Microsoft) compiles a binary. They then take that binary and hash it, producing something like a SHA256 digest. They then take that hash and sign it with a private key that only Microsoft has. Now, Microsoft can distribute the file and anybody who has Microsoft's public key can tell that Microsoft signed the file and that the file hasn't been tampered with since it was signed (assuming that is, in fact, the case). The signature can be stored in the file itself, in a little blob at the end which is not included when hashing the file to verify its signature(s) (otherwise, adding the signature would automatically invalidate it!), or the signature can be stored in another file or otherwise transmitted out-of-band.

A Certificate ties an identity to a public key (which, somewhere, has a corresponding private key). You recognize a certificate is valid - that is, the key it contains really does belong to the person or organization it identifies - if the certificate is signed by the (private) key corresponding to (the public key in) a certificate you trust. Signing a certificate works just like signing a binary or any other file: the certificate (including the name it identifies, the dates for which it is valid, the purpose for which it is to be used, and the public key it is tying to that identity and purpose) is hashed, that digest is signed using the private key of somebody you trust, and the signature (modified digest) is placed back into the certificate in a special location. Of course, to identify who signed a certificate, you need their certificate; this is called a chain of trust and can go until you hit an explicitly trusted certificate. Trusted certificates can be ones where you personally identified the certificate and its owner, or where your software vendor did so (such as a Certificate Authority's certificate, or such as the certificate of the vendor themselves like the way Microsoft ships their own certificate as a trusted one in Windows), or something else like that.

In the context of binaries and code signing, a certificate helps you know who signed your binary, and what the signature is supposed to signify (i.e. Microsoft uses a different certificate and signing key when signing a binary that is a core part of Windows Phone and is allowed to run without a sandbox, as opposed to a binary for an app that must always be sandboxed), and how long it's good for. The signature is made with a private key, but is verified with a public key, so if the public key from a given certificate successfully verifies the signature on a given binary, you know two things: the binary has not been modified since it was signed (this would break the signature, and it would no longer verify) and the owner of the secret key (who is probably the entity identified on the certificate, unless you have a reason to doubt the certificate's authenticity) is the one who signed the binary.

For Windows Authenticode signatures, the certificate is usually included with the binary, so you don't have to get the certificate from somewhere else and can just check the signature immediately. The bundled certificate will be signed by some trusted signer, so you know that the binary wasn't just signed by some random schmoe who put a faked-up certificate with it.

A Thumbprint is just a cryptographic hash digest, usually used to identify a key or certificate. For example, let's say you have a blob of signed data that doesn't have a certificate with it. Checking the public key of each of your certificates to see if it can verify that signature would be slow and silly. Instead, the signature will almost certainly have a thumbprint that identifies the public key which can be used to verify the signature. Rather than attempting a computationally-expensive verification with every one of your public keys, you can just check their thumbprints (which are stored in the certificate, along with the key itself, though you can also just hash the key to get one) until you find the matching key, and then use it to attempt the verification.

One other place where thumbprints come in handy with binaries is catalog files. A catalog file has two parts. The first is a list of hash digests - that is, thumbprints - of other files. The second part is a signature of all those thumbprints. This way, you can distribute a bunch of files (some of which may not be binaries, and may not have anywhere standard to put a signature) that you want to make sure the recipient knows are all yours and haven't been tampered with. You just include a catalog (.cat) file that contains the thumbprints of every file, and is signed with your key. If any of the files were modified, their hash digest won't be one of the thumbprints in the catalog. If somebody tries to edit the catalog, its signature won't verify anymore. If somebody tries to replace the signature on the catalog, they won't have the original signer's private key so they won't be able to produce a signature that can be verified with the original signer's certificate.

Requirements for applying for a Digital Signature Certificate

• Submission of DSC Application form duly filled in by the applicant. Any individual applying for a Digital Signature Certificate is required to fill an Application Form for online submission and verification of personal details by the certifying authority.
  
• Producing Photo ID proof.
  
• Producing Address proof.
  

To fill in the Application form the please log in to the website of the Certifying Authority.