For an executable with a digital certificate, it's easy enough to check for the certificate's information and origin by looking at the executable's properties. For example, here's what is shown for Skype:
These certificates are issued to a developer from a trusted Certification Authority (CA) and are used to sign the executable before distributing it. In theory, the CA should fully verify the identity of the developer applying for a certificate before issuing one, but in practice a CA is still a system involving imperfect entities and it's possible for a malware author to apply for and receive a "good" certificate from a trusted CA while never producing anything but malware.
If you refer back to the first image of the Skype certificates and select "Details", you'll be able to get more information about the certificate and its origin:
In this image, we can see exactly who the certificate was issued to and who issued it, along with relevant issue date and expiration information. This is a direct download from the official Skype site, so I can be pretty confident that the software was made by who it says. Likewise, the certificate was issued by the Microsoft Code Signing PCA, so we can be at least reasonably confident that the certificate is trustworthy. If you look at the "Certification Path" tab, you can trace the certificate all the way back to the root CA and again verify that everything looks as it should.
Determining whether or not the certificate is malicious or stolen can be difficult to detect, but is somewhat a matter of common sense. Does your certificate claim to be issued to a legitimate publisher (e.g., Microsoft) but you know that the software you downloaded is not from them? Something may be amiss. You can also look at the issuing CA and try to find information online about their reputation. Does the CA do a bad job of screening out people who distribute malware? Do they have a reputation for poor information security? If the issuer seems sketchy, then they very well may be. Relying on the reputation of CAs is a known vulnerability.
Now, as to your second question: the certificate consists of a private/public key pair, with the private key kept private (of course) and the public key distributed with the application. Using a code signing tool, a developer generates a hash of the executable and encrypts it with the private key. This hash is distributed with the public key portion of the certificate in the executable. On the user's end, a new hash of the executable is taken and decrypted with the public key to verify its integrity. This means that executables that have been modified after having been signed won't have a valid certificate and you should get a warning when trying to install or run them. If you want to see a list of certificates on your system (both trusted and untrusted), open up a command prompt window and run certmgr
Note that in order for a legitimate certificate to be "stolen" and malware to sign itself with it, it would need access to the private key. If the private key is exposed (like what happened to Dell several years ago...) then it is possible for a malware author to sign their software as if they were the developer to whom the certificate was issued. If this private key is kept private, then it should theoretically be safe. I think the answer to your second question is that you're a bit confused as to how code signing works, but if you did manage to come across a bit of malware that was attempting to generate signed code, I would keep an eye out for sections of code attempting to launch a signtool instance, loading a .pfx or other private key file, etc.
I am not an expert on code signing or certification authorities, so it's possible that there are cases where malware generates self-signed certificates, messes with root CAs on the system, etc., but someone more experienced than me would have to weigh in on that...
As for the dual-signing in your third question, it would be helpful to see an example of what you're talking about, but I did find that Skype is signed with two certificates. The primary difference between the two is the digest algorithm, with one being sha1 and the other sha256. This is likely a mechanism to deal with legacy users who have an operating system for which sha256 is not currently supported and require the older (and deprecated) sha1 digest algorithm. (see: https://security.stackexchange.com/questions/109629/deprecation-of-sha1-code-signing-certificates-on-windows)
For a more in-depth look at code signing and certification authorities, feel free to check out this MSDN article.
