Code Signing vs. Encryption

So, I'm looking for some help, most with understanding the process of code-signing and encryption because I'm still shaky on both topics.

What I think I understand:

First thing needed is a KEY, which is generated using some encryption algorithm (RSA/SHA1/etc)
With this key we create a certificate signing request or CSR (something to do with X509?) which holds all of our information that will be on the certificate (Name, Location, Email, Domain)
Both the KEY and the CSR get sent to the Root CA who then issues a certificate - in the form of a .pem or .p12 file (using the CSR and key for generation).
Something about intermediate CAs and more certificates
This cert can then be used in addition to the intermediate CAs to sign a file so that it basically has your name on it and recipients can be assured it's the what you intended them to receive.

Versus:
Same process with obtaining a certificate
The public key inside of the certificate is used to encrypt the contents of the file using aes and as a result the certificate must be installed on the destination before installing the encrypted file. (this seems secure but not what people would want, secret code that people can't read or decode but still has function)
I guess it makes sense that you can't make the file entirely encrypted because it needs to be decoded to be executed on the target. Am I off on this?

QUESTION: When I sign code using a certificate, does the payload also get encrypted? How is this different than SSL security for a website, ensuring the security and privacy of a connection? It seems like they all use the same technology to accomplish many different tasks.

I'll respond point by point here with some summary / notes about misconceptions later:

First thing needed is a KEY, which is generated using some encryption algorithm (RSA/SHA1/etc)

Yes for the key being the start. Actually in case of signing it's a key pair - you're generating a public / private key pair. You keep the private part, everyone may know the public part. Small correction on algorithms - Sha1 is for hashing, not for encryption. So for certificates it's RSA/DSA/ECDSA normally.

With this key we create a certificate signing request or CSR (something to do with X509?) which holds all of our information that will be on the certificate (Name, Location, Email, Domain)

Yes, to get a typical website certificate (x509 standard) you need a signing request / CSR / PKCS#11 (same thing).

Both the KEY and the CSR get sent to the Root CA who then issues a certificate - in the form of a .pem or .p12 file (using the CSR and key for generation).

No, only the public part of the key (which is already included in the CSR) gets sent to the CA who issues a certificate. Nobody apart from you needs the private key.

Something about intermediate CAs and more certificates

Root CAs don't sign your certificate (for various reasons related to better security and keeping them offline). Intermediate CAs do, and they're signed by the root CA. It means that if you want to use your certificate for protecting traffic to the browser, you need to include the intermediate certs usually. You can verify if everything is in place by checking on https://www.ssllabs.com/ssltest/ - it will tell you if some certificate is missing from the chain.

This cert can then be used in addition to the intermediate CAs to sign a file so that it basically has your name on it and recipients can be assured it's the what you intended them to receive.

Yes. It can be used to sign a file (S/MIME format), but it can be also used to negotiate a secure internet connection.

The public key inside of the certificate is used to encrypt the contents of the file using aes and as a result the certificate must be installed on the destination before installing the encrypted file. (this seems secure but not what people would want, secret code that people can't read or decode but still has function)

What you describe is more like DRM. Only people who have the key are able to read the file, but that doesn't make a lot of sense from security point of view, because you need to give them the key in the first place. You can make the procedure more complex and confusing, but in the end they have to know the other part of the key.

Also, even in that case, you should distribute the public key, not private. You can generate your public key from your private key, but not the other way around.

I guess it makes sense that you can't make the file entirely encrypted because it needs to be decoded to be executed on the target. Am I off on this?

You're right. The only way you can securely execute encrypted software is if you keep the execution engine / key out of reach of software - for example embedded in hardware. This is not realistic for software-only solutions.

When I sign code using a certificate, does the payload also get encrypted?

What do you mean by payload?

The data the application sends - no. That needs to be done explicitly
The application code - no. It's not encrypted, the only thing the signature says is that the person who owns the certificate signed the code and it's not been changed afterwards. Or more precisely, some kind of hash is calculated from the application binary and that short hash is encrypted with your private key. When you distribute your app, everyone can decrypt the signature using your public key and compare the hash to the one you provided.

How is this different than SSL security for a website, ensuring the security and privacy of a connection?

Completely different. TLS is about agreeing on a secret key you use for encryption of data in flight. Code signing is about proving that the code has not been modified and comes from the same entity you (possibly) trust.

It seems like they all use the same technology to accomplish many different tasks.

Yes. It's all based on private/public key pairs. It can be used for many different purposes. X509 certificates actually include a list of purposes they can be used for. The list is: