During an SSL/TLS session there are two types of encryption in use: symmetric and asymmetric. While a key size for asymmetric encryption (2048/4096-bit) depends on the issued certificate and an appropriate private key, a key size for symmetric encryption (128/256-bit) depends neither on the certificate nor on the private key, but on the server’s and browser’s (or any other type of client’s) capabilities and settings only.
Once a connection between the server and the client is established, and a public key encoded in the certificate is sent from the server to the client, the client needs to generate a symmetric key for encryption of the data that will be transmitted further. The client and the server compare their lists of available encryption algorithms and choose the strongest one they both support for symmetric encryption. Nowadays modern clients and servers usually use three algorithms for this:
If your server allows to specify the algorithms that should be chosen during an SSL/TLS handshake, you may force your server to use only 256-bit encryption. Obviously, you should make sure that your server supports 256-bit encryption first. In case of *nix based servers available ciphers usually depend on an openssl library. To find the list of supported ciphers run the command below:
$ openssl ciphers
If you see AES128 in output, you may force your server to use only this cipher for symmetric encryption. For example, in Apache you just need to add the line below in the VirtualHost record where your certificate is described:
Remember that with such configuration clients that do not support an AES(256) algorithm will not be able to establish an SSL/TLS connection with your server. Therefore, such configuration will improve security strength but reduce compatibility with clients.
This option will not reduce compatibility with clients as the previous one but there are still a number of outdated clients, like Internet Explorer 5 or lower which do not support these algorithms and use 40-bit keys for symmetric encryption instead, which is considered insecure today. Certificates with a Server Gated Cryptography (SGC) feature are able to upgrade a symmetric key size even with such clients to 128-bit and seem to be a solution for an optimal compatibility/security balance. However, such outdated clients have a number of other vulnerabilities besides an insufficient symmetric key size, therefore a session with such a client can hardly be considered as secure even in case of certificates with SGC.