What's a certificate signature?

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 signature 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.

Example: Microsoft has a binary they want to sign, a Windows driver. They have a certificate (which they include with Windows) that contains a 2048-bit RSA public key, Microsoft's name, and usage information indicating that it can be used to sign drivers. Because you have Windows, you have this certificate and it is automatically trusted. Microsoft computes the SHA256 hash digest of their driver binary. They then take their the RSA private key corresponding to the public key in that certificate, and use the private key to sign the digest. The modified digest (signature) and the digest (thumbprint) of the public key that can verify it are placed in a special area at the end of the binary. They then publish that binary.

When you download the driver and try to install it, Windows checks for a signature on the binary. Seeing that there is a signature present, it checks its trust store (list of trusted certificates) for a certificate whose public key has the same fingerprint as the one included with the signature. Finding the matching certificate, Windows verifies that the certificate can be used to indicate a trusted driver, and then re-computes the SHA256 digest of the binary (ignoring the part at the end where the signature is). Windows then uses the RSA public key from the certificate and performs an operation with that public key upon the signature. If the result of the operation matches the digest that Windows just computed, it knows that the binary was signed by Microsoft (because only Microsoft has the right private key for that public key), and that the binary hasn't been modified since. It thus determines that the binary is trusted and may be loaded as a driver.