1
$\begingroup$

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?

$\endgroup$
  • $\begingroup$ Actually, with many (TLS) configurations, chances are you're gonna use your static server key for signing and encrypting (e.g. if you enable static RSA key transport and the (EC)DHE cipher suites) $\endgroup$ – SEJPM Sep 23 '16 at 21:04
  • $\begingroup$ It appears that the ietf is dropping rsa key transport in tls 1.3. How would one use separate keys to sign and encrypt in tls 1.2? $\endgroup$ – anotheruser Sep 23 '16 at 23:29
1
$\begingroup$

First of all, you cannot use a private key for signing and encryption, you'd use it for signing and decryption.

In PKI/TLS/SSL asymmetric encryption is not used to transmit the public key when RSA session key agreement is used. The public key is within a (signed) certificate, the private key stays at the server.

Once trusted, the public key can be used to encrypt the master secret, which is used to derive the session keys.


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

So no, that's not how it is used. That said, sometimes the same private key is used for signing or decryption within TLS. This happens when both asymmetric (DH) key agreement and RSA encryption are used within the enabled ciphersuites. Within DH key agreement the private key authenticates the parameters rather than decrypting the master secret directly.

Although separating different uses of keys is good practice with regards to key management. That doesn't mean that using the keys for authentication and decryption will suddenly destroy all security however. Using different keys for e.g. long term signatures (e.g. document signing) and real-time authentication makes a lot of sense.

To use different key pairs it is normally sufficient to use different certificates / certificate chains. The (TLS) software should pick up on the correct key usage and should therefore not use a certificate / private key pair for the wrong purpose - but that is of course implementation specific. In other words, don't assume but test you specific TLS configuration.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.