To my understanding, if a server “cert+key” (RSA) is compromised, than the SSL/TLS network traffic can be decrypted.

What about a client “cert+key” (RSA)? Could someone reuse client certificates?

For example: can somebody with the client “cert+key” decrypt (or in otherwise mess with) the traffic of another user? (Yes, I know they can impersonate but that is not my question.)

  • $\begingroup$ A leak of the server side key only compromises past traffic if the RSA key exchange was used, not if (EC)DHE_RSA was used. $\endgroup$ Commented Dec 11, 2013 at 14:13

2 Answers 2


To answer this question, we must have a look at how TLS/SSL works.

I guess you know that the aim of TLS/SSL is to authenticate communicating parties before setting up an encrypted connection through which application data will flow. And as you may already know, an SSL handshake/session will use asymmetric crypto for authentication and session setup and symmetric crypto for application data.

If you look at how a client-authenticated TLS handshakes are made, the only moment where asymmetric crypto may be used aside authentication is when the parties agree on the premaster secret (random data that will be derived into the symmetric key for the session). There are 2 ways of doing this (depending on the chosen cipher suite):

  • The client generates a 48 byte premaster secret and encrypts it with the server's public key
  • Or, the client and the server do a standard DH/ECDH computation (with ephemeral keypairs proper to this handshake) to agree on a premaster secret

You notice here that no information from the client's certificate/keypair has been used after the authentication. Therefore, if a user has his certificate/keypair compromised, it will/should not affect the other users.

  • $\begingroup$ thnx, that's what I thought. the client keypair is only used for auth not key xchng, unlike the server keypair where it is used for both (depending on the cipher suite) $\endgroup$
    – SteelBytes
    Commented Dec 11, 2013 at 9:26

If you use public key crypto in the correct way, then every user has it's own private key and corresponding public key (included in the certificate) and the keys of users are not related. Consequently, compromising the private key of one user does not affect any of the other users. So in the case of compromise of the private key of one user the remaining users are safe.

There are examples where you would run into problems, e.g., if using common modulus for RSA - but if the user's private keys are generated correctly, i.e., independently with independent and good randomness - as it should be done in practice - then there will be no problem. It is, however, known that bad randomness is partially used in practice, e.g., resulting in RSA moduli that share at least a prime factor. You can find more information for example here or another example here.

Clearly, if you use public key crypto in the wrong way and give a private key to several users, then you will have this problem or if you use bad randomness you may also run into these problems. But you should not do that!!

  • $\begingroup$ yes, but this does not address my question. $\endgroup$
    – SteelBytes
    Commented Dec 10, 2013 at 5:15
  • 1
    $\begingroup$ Then you should make it more explicit what your question is ;) Someone can re-use the certificate if he knows the corresponding private key. Obviously, I do not get your point :/ $\endgroup$
    – DrLecter
    Commented Dec 10, 2013 at 5:18
  • $\begingroup$ I think steelbytes is indeed referring not to compromise of the server key / certificate but to that of another client as in the answer of Syrian. I don't think it is very clear in the question either, and your answer is as valid for that scenario as well. (sorry for the bad sentence, I'm not fully awake) $\endgroup$
    – Maarten Bodewes
    Commented Dec 10, 2013 at 9:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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