client certificates in .NET

can anyone explain to me the difference between client certificates and the public certificates we see in SSL?

why do we need a private key in client certificates?

i currently have a client certificate that does not have a private key associated with it and IIS keeps asking for a priv开发者_如何学运维ate key.

please help!

---

Client certificate is used (as its name suggests) to authenticate the client to the server during SSL/TLS handshake. In order for any certificate to be used for authentication, the authenticating party must have a private key, which is a proof of authenticity (in other words, the one who owns the private key owns the title). Consequently, if you use some certificate to authenticate a client, you must have a corresponding private key. The private key never leaves client side, it's only used in certain cryptographic implementations.

However, your question is confusing. On the server you usually authenticate the server to the client, and you use server's certificate for this. You can tell the server, that certain client's certificate is trusted and the client can authenticate itself using this certificate, but you don't need client's private key for this. So you are doing something wrong with IIS.

---

I currently have a client certificate that does not have a private key associated with it

This is a contradiction in terms. Every certificate has a private key associated with it. It is installed at the client along with the certificate. It was generated prior the certificate in fact. The certificate itself can be exported, but this is without the private key. This is done e.g. to get the server to trust the client if the client certificate isn't signed by someone the server already trusts.

---

A certificate contains a public key of a key pair. Somebody holds the private key of the key pair, and keeps that secret. It is stored separate from the certificate, unless you bundle them together to transport them, in a PFX file, for example.

When the server has a "server certificate", that's a certificate with a public key in it, and the server also has the private key kept safely somewhere. It uses the private key to sign something on the SSL handshake. The client only needs the server certificate, which only has the public key of the server's key pair, to verify that signature, to determine that the server does in fact hold the private key of the server key pair.

When the client sends a "client certificate" on the SSL connection for client authentication, then the client will have it's own private key kept safely on its side. It's possible to neglect to import the private key when you import a client certificate on the client machine, when the certificate was generated somewhere else. But the client will need to have that client private key in order to sign something in the SSL handshake, to prove to the server that it holds the private key of the client key pair.

The server only sees the client certificate, which only has the public key. The public key, along with the something that the client has signed, proves that the client holds the private key. Neither side sends its own private key to the other side. They only send the certificates, which only carry the public key along with the certificate stuff (common name, issuer, etc.)