How to distribute client certificates without exposing private key?

Question

I'm desgining a B2B web service based on WCF. As the number of clients is relatively small and security is a priority, i have chosen to go with X509 client certificates for client authentication.

I'm signing the client certificates with my own self-signed CA (which of course is being kept safe). I have also verified that the setup is working on a local set of computers.

One problem keeps bugging me though. As long as the certificates can be "physical" handed over i have no problem. However i can't seem to find a solution for safely transfering the client certificates to the actual clients. These are the options i have come up with so far:

1) Encryptering the certficates using symmetric encryption in PFX format. Then i'll e-mail the certificate and send the key for decrypting the certificate with good old snail-mail (that is, a physical letter)

2) Build a simple website that let's the clients log-in using a temporary URL (credentials sent to e-mail address) and then download the certificate. The site would be secured using HTTPS. The security then fully relies on the security of the clients e-mail and that no-one picks up the URL from the e-mail

I tend to prefer option 1) as the only security flaw there would be for someone to actually steal the key from the physical letter. However it seems a bit tedious to use a physcial letter.

Is there any de-facto standard for solving this issue that i am overlooking that provides reasonable security?

Answer 1

The "normal" way of doing certificates is that the private key never leaves the client system. Things go like this:

• The private/public key pair is generated on the client system.
• The public key is sent to the CA as part of a certificate request (normally PKCS#10 format).
• The CA builds and signs the certificate, which is sent back to the client.

The critical part now becomes making sure that the CA is talking to the right client at issuance time; but, at least, only public data is transferred, which makes things simpler.

I suggest that you send to your prospective clients a one-time password by mail -- not email, but the more traditional paper-based mail. They then use it to enroll on your CA (within HTTPS, of course). Make your life easier: use a CA product which already includes the necessary software and process.

Answer 2

Your analysis of the problem seems to involve the idea of an infinite time window.

Consider transmitting the certificate via HTTPS and having your backend allow the certificate to be transfered only one time. Unless the transfer connection itself is MITM'd, your customer will either have a certificate that nobody else has or they will know it has been retrieved by somebody else. You'll end up revoking some non-negligible amount certificates due to customer failures to save, etc. when they ask for re-issues, but you'll know that only one person has accepted the cert or that it should be invalidated.

Answer 3

You could have the client generate a certificate signing request, and send that to you to be signed by your CA. Generating the CSR on the client will create the public/private keypair, and the CSR will only contain the public key and identity info. That way the private key is never transferred over the network.

There are products out there that will do just this, and have multifactor auth integrated. You will have to look for them.

If you want to code the above, MS systems use an ActiveX and html5 has a keygen function that will do what I described above.