3

I'm a bit of a newbie to WCF and web security, so I'd really appreciate a clear explanation of the following concepts:

I understand that if I want to create a secure connection to a web site, I need to have an SSL certificate from a trusted authority, e.g. Verisign, Thawte, etc.

Now I'm writing a SaaS app that has a central web service, and and number of client applications that connect to the central web service. I want to conduct all communication between client and server securely, so I have got a SSL certificate on my server.

But WCF now comes with this concept of a "client-side certificate", which appears to be required to validate my server-side certificate, and which I totally don't understand. The client is going to be downloaded by some anonymous guy halfway across the world. I have no idea what certificates he will or won't have installed - nor do I care! All I want is for the communication between the client and server to be secure. Am I supposed to install my own certificate on the client somehow?

Can somebody please explain these concepts to me?

(And while you're at it, I have a related question here with a bounty on it.)

Community
  • 1
  • 1
Shaul Behr
  • 36,951
  • 69
  • 249
  • 387

2 Answers2

2

I think you are combining two different things. SSL is based on asymetric encryption which works with two different keys - public key and private key. Encryption works in the way when anybody can use the public key to encrypt data but only holder of private key can decrypt data. When you install service certificate on your server you must install certificate which contains both keys but your clients need certificate which contain public key (otherwise they will not be able to encrypt messages for your service) => Client must have access to certificate with public key. When using trusted certificate authority this should not be a problem because SSL (at least HTTPS) should exchange this certificate during initial handshake.

Client certificate has differnt meaning. It is usually used for client authentication (instead of user name and password). In case of message security it can be also used to build full two way asymmetric encryption and signing (SSL uses asymmetric encryption only to excahnge unique key for symmetric encryption).

Ladislav Mrnka
  • 360,892
  • 59
  • 660
  • 670
  • Actully, SSL/TLS do support the use of certificates for client authentication during the handshake. See http://tools.ietf.org/html/rfc5246#page-55 – Yhrn Feb 21 '11 at 20:35
  • @Yhrn: I think I wrote it in second paragraph. – Ladislav Mrnka Feb 21 '11 at 20:39
  • The way I interpreted it, you were saying that client certificates could be used for message security (which means WCF uses WS-Security, i.e. signed/encrypted XML) and not for transport security, i.e. SSL/TLS. Sorry if I read it wrong. – Yhrn Feb 21 '11 at 20:45
  • @Yhrn: Ok, sorry I didn't mean it this way. Only second part of paragraph was about message security. – Ladislav Mrnka Feb 21 '11 at 21:07
2

Not to worry - client side certificates are not required to validate the server certificate. As long as all you want to achieve is that the client knows for sure that he or she is talking to your server and that nobody else can eavesdrop or alter the communication a server certificate is all you need. However, as I described in my answer to your related question, the client do need to trust the server certificate (and this is probably where your problem lies).

Client certificates comes into play when the server wants to authenticate the identity of the client in a more secure manner than using passwords. SSL/TLS (including HTTPS which is simply HTTP over SSL/TLS) do support client certificates and it is often referred to "double sided SSL" or "SSL with client authentication". All major browsers support this and so do WCF clients but as I said earlier it is not required (unless the server requires it explicitly).

Yhrn
  • 1,063
  • 7
  • 16