Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In a classic PKI scenario, the certificate authority receives signing requests generated by an end-user which owns the keychain, and thus has his private key secret.

Consider a scenario in which the CA not only signs certificates, but also generates the requests for the end-user, thus essentially having a copy of all the private keys in the system.

What properties of the PKI are violated in this case? Which attack vectors does this scenario open?

Edit: I should've mentioned this is not in the context of SSL/TLS. Rather, case in point is an organization acting as a CA (and VA, and RA), and creating identification cards for individuals.

share|improve this question
up vote 3 down vote accepted

I agree with binaryanomaly's answer, except even in the normal operation (where your private key is kept secret) any CA can already impersonate any other user's identity. The CA merely needs to create a new CSR (for a private key they possess) and then sign it, so now there is a new certificate (that your browser will inherently trust). Then if they can eavesdrop/alter your network traffic, they could MitM any SSL connection relying on CAs for trust.

Granted, in principle you could detect that the certificate has changed in this scenario (if you actually examine the certificate and look at the modulus or signature). With the lost private key model, the CA could use your private key to decrypt your traffic passively, without having to do a MitM attack that replaces your certificate with one that they have the private key for.

share|improve this answer
If you cannot trust CAs then the whole system is useless as the CAs are the anchors of trust of that system. Still it's a different thing to provide the private key to the CA. – binaryanomaly May 5 '14 at 19:54
@binaryanomaly - I agree, there's no reason to share your private keys with the CA, so its best not to do it. It's risky for a CA to do a MitM attack I described. A careful user may notice the cert changed and merely has to download the fraudulent certificate to prove to the world that the CA is compromised. If that happens, the CA would likely lose their trusted root status in browsers and go bankrupt like DigiNotar did in 2011. Meanwhile, if a CA kept your private key they could impersonate you or decrypt traffic in an undetectable manner. – dr jimbob May 5 '14 at 21:23
drjimbob, @binaryanomaly - See my edit, this isn't neccesarily in the context of SSL/TLS. – Yuval Adam May 5 '14 at 22:00
My comments where not restricted to TLS but rather to PKI/CA in general. – binaryanomaly May 5 '14 at 22:09
@YuvalAdam - While I did specifically refer to browsers and SSL/TLS (as that is presently the primary use case of CAs), the principles are generic. Any CA can generate a fraudulent certificate and use it as if they were you in MitM attacks -- either to encrypt/decrypt messages or to sign messages (granted careful applications may notice the certificate changed). But anyone who knows the private key corresponding to a certificate, can use it in an undetectable way (exactly as if they were the legitimate certificate owner) which is a more powerful attack. – dr jimbob May 5 '14 at 22:56

The PKI system is then broken by concept. A private key is meant to be secret and private to you. You would not share it with anybody you don't fully trust - certainly not with the CA.

The entity having a copy of the private key could 'impersonate' you digitally.

I would recommend you to read a bit about the basics of PKI

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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