gmail.com Google, fb,... use RC4-SHA. How does one create RC4-SHA self signed cert ?
Or even with aes128 key ? I tried using using "genrsa -aes128", resulting cert was DHE-RSA-AES256-SHA
openssl genrsa -aes128 -out 1.key 1024 openssl req -new -key 1.key -out 1.csr cp -f 1.key orig.1.key openssl rsa -in orig.1.key -out 1.key openssl x509 -req -in 1.csr -signkey 1.key -out 1.crt
The certificate has (almost) nothing to do with the encryption used in the SSL/TLS communication. The only purpose of the certificates used by the websites you mention is to authenticate the server.
RC4, AES-128, AES-256 are the encryption algorithms used by the SSL/TLS channel itself. In this context, SHA is the MAC algorithm name (used to ensure the integrity of the communication).
Both are encryption and MAC algorithms are set up with the cipher suites, which are configured on both client and server, and are (relatively) independent of the certificate. The only dependency is that some cipher suites require a certificate with an RSA key, others a certificate with a DSA key.
If you look at the cipher suite list in the TLS 1.1 specification, there are cipher suites for RC4-SHA, AES128-SHA and AES126-SHA with RSA keys. Any modern certificate with an RSA key should be able to supports these, provided that the SSL/TLS stack you want to use also supports them, and is configured to do so.
(You may also be interested in this question.)
In openssl genrsa -aes128, -aes128 is used to tell OpenSSL how to encrypt the private key it's generating (in the file itself).
The cipher used depends on the client and server's SSL handshake; it is not dictated by the key pair itself. During this handshake, the client and server show what algorithms they support, and the server will typically choose the strongest available cipher.
The public/private keys can be used to accomplish three main goals; integrity, authentication, and confidentiality. However, it does not have to accomplish authentication as SSL/TLS can be implemented with total anonymity.
From page 34 of TLS 1.0 (RFC 2246):
The CipherSuite list, passed from the client to the server in the
client hello message, contains the combinations of cryptographic
algorithms supported by the client in order of the client's
preference (favorite choice first). Each CipherSuite defines a key
exchange algorithm, a bulk encryption algorithm (including secret key length) and a MAC algorithm. The server will select a cipher suite
or, if no acceptable choices are presented, return a handshake
failure alert and close the connection.
From page 91 of TLS 1.2 (RFC 5246):
TLS supports three authentication modes: authentication of both
parties, server authentication with an unauthenticated client, and
total anonymity.
Also, see here for a simpler description of the SSL/TLS handshaking process.
It is also important to note that this cipher is only used when performing the handshake and exchanging the symmetric key which, after it is agreed upon, is used exclusively for the rest of the session UNLESS the secret key is set to be renegotiated.
