How to use separate keys for signing and encryption I read that the same key should not be used for both certificate signing and encryption.

I wonder if this is not a problem with PKI/TLS/SSL, the reason being asymmetric encryption is used to transmit the public key (via the certificate).  The public key is used to encrypt a browser generated session key.  The session key is used for symmetric encryption of the actual traffic.

Is that how it works and does that mean it is okay to sign both with the same key?

How would I go about using separate keys?
In TLS 1.2 the Client proposes a list of suites of primitives they are willing to use for TLS. This takes place in clear in the ClientHello message.
You could examine that list and decide one of three things:

The list has a nice modern Forward Secret Diffie-Hellman-style key agreement method you're comfortable using with RSA signatures. You present Certificate #1 for RSA Key #1 and you use the corresponding Private Key to sign stuff in TLS. Certificate #1 says this RSA key is suitable for this purpose (specifically it should set the Key Usage bit 0 digitalSignature).

The list says the client is willing to do RSA key agreement. You present Certificate #2 for RSA key #2 and you use the corresponding Private Key to decrypt the key agreement message from the client. Certificate #2 says this RSA key is suitable for this purpose but not for signing things (probably setting bit 2 of Key Usage aka keyEncipherment -- it should definitely not set bit 0 digitalSignature).


OR 3. You can't accept any of these methods and give up.
Having chosen to behave this way you can now also do TLS 1.3, you should always use Certificate #1 (and the corresponding key) because in TLS 1.3 there is no RSA key agreement mechanism since it is considered dangerous. Because you are using separate keys, a client which is careful about validating Key Usage information can discern that it should not trust Certificate #2 in TLS 1.3 (or doing DH key agreement in TLS 1.2) and so if an attack on your decryption in scenario #2 above is successful those clients are protected and only clients willing to undergo scenario #2 themselves are affected.