Must the person who requests an SSL certificate have their private key on their machine? [closed]

Question

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.

Closed 9 years ago.

Improve this question

I am trying to create on the server side certificates for my website users so they could authenticate themselves, instead of the basic authentication I already offer which is username/password.

Can I do the whole process of generating the public/private keys for creating the CSR, on the server side instead of on the client side?

I was thinking of the following process:

The user logs into the website and authenticate themselves by username/password.

The user will submit identifying details through a web form over SSL connection between the user browser and the server.

Then the server will create the public/private keys for that user, and use these to create the CSR on the server. Then the server will use the CSR to create the certificate for the user. Then it will send the certificate to the user over SSL. Then the server will erase the created public/private keys.

Finally, the user will install the certificate on their browser.

Is this going to work? Is it unsafe in some way? Is it okay to move like that from the client side to the server side the responsibility of creating the public/private keys for creating the CSR? Will this make the created certificate less useful in some way for the user?

Answer 1

Does the person who requests an SSL certificate must have their private key on their machine?

Yes. The client cannot present the certificate as their own in the SSL handshake without the private key, as a digital signature with that key is also part of the SSL handshake, to verify that the client owns it. If the client didn't need the private key to present the certificate, anybody could present anybody's certificate and the whole system would be completely pointless.

Is this going to work?

No.

Is it unsafe in some way?

Yes.

Is it okay to move like that from the client side to the server side the responsibility of creating the public/private keys for creating the CSR?

No.

Will this make the created certificate less useful in some way for the user?

Yes.

It isn't going to work. You have to find a secure way for the private key to exist on the client machine.

What you're proposing is completely and utterly invalid and insecure. The private key is supposed to be private to the person that owns it. If anybody else knows it, it cannot perform the function for which it is designed. Specifically, anybody who has it can impersonate the owner. People who design workflows like this are letting themselves in for a world of legal pain. Have a think about loss of non-repudiation for a start.