WCF client error “The private key is not present in the X.509 certificate”

Question

I'm stuck trying to get a WCF client to communicate to an IIS Hosted WCF Service with TransportWithMessageCredential.

In this scenario we will have about 20 clients all running the client app. It is planned they will all use the same certificate to communicate with our server to provide encryption (identification is handled separately). Our server root web site is already configured with a certificate. The WCF service will be running from a sub-site and I wish to use this same certificate to secure access from our client app to the service.

If I install a PFX certificate on the client everything is fine. But I do not want to export the Private Key from our server - wouldn't this be a security issue?

If I install a CER certificate file, run my client app, I get the error - “The private key is not present in the X.509 certificate” - sounds reasonable as I did not export one

Maybe I'm missing something; I have googled this a lot and most solutions state to export the private key.

Is there any way to use a CER certificate file without exporting the private key from our server? Or what is considered best practice.

Thanks for any advice.

Answer 1

I need an answer to exactly the same question...

It seems ludicrous that after going to all this trouble to encrypt things with 128 bit keys, wading through an indecipherable mess of acronyms and using prime numbers as large as my credit card balance etc etc... after all that trouble you'd go and export your private key to each and every client machine, only protected by a (possibly insecure) password on the certificate file. Crazy stuff. Pointless.

One thing to remember is that both server and client need to decrypt messages and decryption requires the private key apparently.

So they only way I can see to avoid shipping your server's private key to all and sundry is to have 2 unrelated certificates, one for the server and one for the client.

When a message is sent from client to server, the client encrypts using the server's public key only. The server then decrypts using its private key.

When a message is sent (or a reply more like) from server to client, the server encrypts using the client's public key and the client decrypts using its own private key. Voila?

At least that way the server's private key is never released outside the server. The client private key is still shipped everywhere however.

I think it then boils down to 4 scenarios that are handled with varying degrees of satisfaction -

1) Msg sent from client to server - msg encrypted using server's public key. Server cert must be available on client. Server private key does not have to be present. Would be relatively easy for a rouge client to encrypt and send a message to the server as the server's public key is readily accessible.

2) Msg received on server - msg is decrypted using server's private key. This private key only resides on the server so is pretty secure (physical security?). The server certificate containing the private key shouldn't be accessible to others unless you put a copy in a public FTP folder, or enable remote access, or something daft. And even if someone gets the server certificate, they still need to guess your brilliant password right? As an aside, I have no idea of password protected cert files can be "cracked".

3) Reply sent from server to client - msg is encrypted using client's public key. So server needs client cert (private key not needed). The client public key is again easily available everywhere, so it would be pretty easy to intercept original msg from client to server, ignore its content (as you can't decrypt it without the server's private key), and send some kind of encrypted response back to the client just to see how the client interprets it. Fun.

4) Reply from server received by the client - msg decrypted using the client's private key. This private key is on ALL client machines, in the certificate file, ONLY protected by a password... so it's relatively insecure.

Of course the other option, if you're not too worried about security, is to ship the server certificate everywhere (including server private key) and use it as both the server AND client certificate. I'm sure a lot of people do that.

This answer contains a fair bit of speculation & dot joining, as I can't find a clear explanation out there. I'd be interested to know if I've got close.

=================================================================================

Update: getting there - http://msdn.microsoft.com/en-us/library/ms733102.aspx