0

I have a WCF Server Deployed through IIS. I want to Create a Certificate for it. I could do this by making the server a certificate server.

But then when the client connects to that server I want the client to automatically trust the certificate without having to register that the server as a "trusted authority".

Is this possible?

All this seems a lot of work to put username password protection on a WCF Service!

Keith Nicholas
  • 43,549
  • 15
  • 93
  • 156
  • You don't need a certificate for username/password authentication. Are you trying to do Mutual Certificate auth, or Username-over-Transport? The answer's a bit different for each. – Aaronaught Jan 26 '10 at 04:44
  • in WCF, how do you do username/password authentication without a certificate? – Keith Nicholas Jan 26 '10 at 04:46
  • @Keith - in WCF you can't use basic, message based authentication unless you spoof a behaviour that fools WCF into thinking that the transport is secure. You would generally only do that if you know something that WCF doesn't (that the transport is secure when WCF doesn't think so). – David Hall Jan 26 '10 at 04:52
  • Use a custom validator. You can configure it in the `userNameAuthentication` configuration element. – Aaronaught Jan 26 '10 at 04:55
  • 1
    Incidentally, this isn't secure and you *shouldn't* do it. I'm just saying that you *can*. – Aaronaught Jan 26 '10 at 04:58
  • Aaronaught, thats what I'm doing....but that catch is, you have to do this over a secure connection..... hence you need public/private key encryption, etc etc – Keith Nicholas Jan 26 '10 at 20:34

3 Answers3

2

The short answer is no the client will need to add the server cert root as a trusted authority.

The slightly longer answer is that there is a workaround for needing to implement transport security in WCF when using message based authentication - this workaround is usually used when you want to rely upon another security mechanism that the WCF server is not aware of, like an ISA server providing SSL.

Have a look at Yaron Naveh's post. The essential idea is that you create a transport binding that pretends that it is secure.

With all that, you still need security (you don't want to send your creds in the clear) and so will still need a trust chain for your cert. So, it may not actually help you, but hopefully it gives you some options to consider.

Edit

Sorry if my answer was misleading. The server certificate root cert must by in the client trusted store. My additional detail was giving another option for providing the security (you can use an ISA server with a trusted cert to give your SSL connection)

In a similar situation to yours (needing secure communication when pushing client applicaitons to non technical customers) I have programatically installed the needed root certs.

Here is an SO post that details how to do that: How can I install a certificate into the local machine store programmatically using c#?

Community
  • 1
  • 1
David Hall
  • 32,624
  • 10
  • 90
  • 127
  • ok, so can I automatically accept the cert on the client side? basically I dont want the client program have to do anything special other than fill in their username / password – Keith Nicholas Jan 26 '10 at 04:40
  • @Keith No - sorry if my answer was misleading. You will need your client to have the root of your certificates trust chain in the store. I've posted a link to an SO post detailing how to install certs programatically. – David Hall Jan 26 '10 at 04:46
2

You can if you add this to your code but be aware of what you are doing!

System.Net.ServicePointManager.ServerCertificateValidationCallback += ( se, cert, chain, sslerror ) => { return true; };
Krumelur
  • 32,180
  • 27
  • 124
  • 263
1

Well if there would be such a way, it would be a security hole.

If a certificate is not linked to a trusted authority it is easily forged. So your choice is either to link it one way or another (directly or through a parent certificate you control), or configure your client so that it does not require the certificate i.e. using http rather than https.

Just keep in mind that it leaves your clients open to a variety of attacks

Edit

One of the possible attack scenarios is a man in the middle attack - a program inserts itself between your service and the client and channels the information though itself. This way the intruder has complete control over the information flow.

It can make copies of passwords or it can "adjust" the results in both directions any way it wants. The only thing which prevents this from happening is the certificates. But if they are not rooted, they can be forged.

mfeingold
  • 7,094
  • 4
  • 37
  • 43
  • With a WCF service, doing message based authentication across http is not possible without using a workaround like I mention. And as you say, employing such a workaround is generally a bad idea unless one knows what one is doing. – David Hall Jan 26 '10 at 04:35
  • I don't see how there's a big security hole.... I want clients to be able to connect, they still have to send a password and username. In WCF you can't do that unless its over an encrypted connection...hence the whole needing of certificates....essentially I don't care that the host has valid client or the client is connected to the right host... I figure this is mainly a man in the middle protection scheme. – Keith Nicholas Jan 26 '10 at 04:40