Understanding 2048 bit SSL and 256 bit encryption

The 2048-bit is about the RSA key pair: RSA keys are mathematical objects which include a big integer, and a "2048-bit key" is a key such that the big integer is larger than 2²⁰⁴⁷ but smaller than 2²⁰⁴⁸.

The 256-bit is about SSL. In SSL, the server key is used only to transmit a random 256-bit key (that one does not have mathematical structure, it is just a bunch of bits); roughly speaking, the client generates a random 256-bit key, encrypts it with the server's RSA public key (the one which is in the server's certificate and is a "2048-bit key"), and sends the result to the server. The server uses its private RSA key to reverse the operation, and thus obtain the 256-bit key chosen by the client. Afterwards, client and server use the 256-bit to do symmetric encryption and integrity checks, and RSA is not used any further for that connection.

See this answer for some more details. This setup is often called "hybrid encryption". This is done because RSA is not appropriate for bulk encryption, but symmetric encryption cannot do the initial public/private business which is needed to get things started.

(SSL can do the key exchange with other algorithms than RSA so I have simplified description a bit in the text above, but that's the gist of the idea.)

To add a little more detail, the 2048 bit RSA key is something called asymmetric cryptography. It is used for validating identity (signing) and ensuring that only an intended recipient can access the information sent (encryption). It is composed of two pieces, a public key and a private key. The keys are actually related to each other, but because they are related by two very large pseudo-prime numbers (prime in relation to each other) they are very hard to figure out the private key from the public.

That said, because the algorithm is based on something that is simply really hard to figure out (but is solvable), it is less secure than a symmetric algorithm based on a shared secret, which is not mathematically solvable and does not rely on the complexity of a math problem for security (more on that later). This is why the key is so much larger than the symmetric counterpart (which is only 256 bits). To make the equation hard to solve requires the much larger key and also, the more information that is transmitted with the asymmetric key, the more likely it is to be broken (also, the encryption/decryption is more processor intense).

For this reason, SSL only utilizes RSA for the validation and key exchange phases. Instead, a symmetric key (in this case of 256 bits if supported by the browser on the client) is generated and transmitted back to the server via RSA encryption and then the rest of the data is exchanged via the shared key and a symmetric algorithm.

This occurs by the client first decoding the response to a challenge which the server encrypts with it's private key, the client can then look at the public key of the server (which is signed by a known root key that the CA(in this case DigiCert) has had included with most browsers). When the decoded response matches the challenge, the client knows that the server responded to the request (though there may be a middle man relaying it). The client then generates the 256 bit symmetric key and encrypts it with the server's public key and sends it to the server. Because the key is encrypted with the server's public key, only the server (which knows the private key) can decrypt it. This means any middle man in the previous step can not know the new shared key. The client can now trust that any information sent via the shared key comes only from the intended server.

Just to add some details to the existing answers...

my question is how would the client know to generate a random 256 bit key? (Why not 128?).

This depends on the the cipher suite that is negotiated. The list of those defined as part of TLS 1.1 is in RFC 4346 Appendix A.5. For example TLS_RSA_WITH_AES_128_CBC_SHA will use a 128-bit key, whereas TLS_DHE_RSA_WITH_AES_256_CBC_SHA will use a 256-bit key.

Which cipher suite is negotiated will depend on the client and server configuration, not on the certificate installed on the server. When the client initiates the connection with a Client Hello message, it sends a list of cipher suites it supports. The server then picks the one it wants and says so in its Server Hello message.

This cipher suite then determines how these symmetric keys are eventually shared. The immediate purpose of the SSL/TLS handshake is to establish a share pre-master secret between the client and the server. This is more broadly referred to as the key-exchange (see RFC 4346 Appendix F.1.1).

This falls in two categories (excluding anonymous key exchange):

• RSA key exchange (e.g. TLS_RSA_WITH_AES_128_CBC_SHA): the client encrypts the pre-master secret using the server's public key (found in the certificate).
• DH(E) key exchange (e.g. TLS_DHE_RSA_WITH_AES_256_CBC_SHA): a Diffie-Hellman key exchange takes place. The server signs its DH parameters and the client verifies the signature against the public key in the server certificate. (Having an RSA-based certificate doesn't imply an RSA key exchange.)

At the end of the handshake, whichever of these two steps were used, the client and the server are in possession of a common pre-master secret, from which they derive a master secret (see RFC 4346 Section 8.1).

From that master secret, both parties can derive the encryption keys (and MAC secrets), as described in RFC 4346 Section 6.3.

Besides the key type (RSA or DSS), there is nothing in this that makes the size of the encryption key depend on the certificate. In addition, both types have cipher suites that use 256-bit keys: for example TLS_DHE_DSS_WITH_AES_256_CBC_SHA and TLS_DHE_RSA_WITH_AES_256_CBC_SHA. (DSS is a signature-only algorithm, so you wouldn't get an RSA-like key exchange to encrypt the pre-master secret.)

The size of the key in the certificate only matters to prevent forgery of the key exchange (or to be able to decipher recorded traffic back): if someone was able to find the private key from the public key in the certificate, they could act as a MITM to impersonate the real server or they would be able to decipher the enciphered pre-master secret (and thus the recorded traffic) when using an RSA key exchange (DHE cipher suites are precisely designed to prevent getting access to the pre-master secret, even if the attacker gets hold of the private key and the recorded traffic, see this question). This is why a sufficient large asymmetric key matters.

Certification Authorities tend to put "256 bits" on their websites because it looks good from a marketing point of view.

It's not wrong, but it can be misleading for people who don't understand that it's how your server is set up and what your clients support that matters.