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?


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.

  • That seems reasonable. When you say CA product, is that something like GlobalSign, or do products exists which can be installed on my own server for signing client certificates? If i'm using an external provider, do they typically have a site where i can log in and "authorize" signing requests? – Henrikmh Nov 13 '12 at 10:55
  • I'll just clarify the last part: If using an external provider, i would need to either make some kind of integration to them so they could verify the password that i sent out (either by manually logging and verifying the password or them doing a callback to my system), or have them send out the letters in the first place. – Henrikmh Nov 13 '12 at 11:00

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.

  • That would actually be a quite simple, yet pretty secure solution. Quite similar to my 2) approach, but the idea about deleting the certificate after the first download is great. I would prefer the CSR approach which the other two guys mentions, but if that turns out to be too time consuming or expensive, then i'll probably go for this. – Henrikmh Nov 13 '12 at 10:57

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.

  • Seems similar to Tomas' suggestions. Do you know any such products? I dont think the cost/benefit of coding such a solution would be very good, but if there exists a solution which can be implemented quite easliy and isn't too expensive, this would be a great solution. – Henrikmh Nov 13 '12 at 10:58

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.