What is the significance of this tag in the WCF client config? What does it actually mean. I have seen people put the name of their certificates in this tag like
<dns value="CertificateName">
Can any WCF experts out there give me a detailed explanation...
I am assuming that the dns tag is the client -> endpoint -> indentity -> dns tag.
In that case the value is the name of the server that the client expects to be talking to.
http://msdn.microsoft.com/en-us/library/ms733130.aspx
If you want to use a certificate to identify the service you would use the certificate tag or the rsa tag.
The service is identifying itself by means of a certificate installed on the machine where your service is running.
The <dns> tag defines what the "subject name" (or identity) of that service certificate is going to be, so that the client can check to see whether the certificate presented by the service to "prove" its identity is really what it expected it to be.
There's a really good set of blog post here that talk about WCF security scenarios - one of them (part 4) is Internet scenario which mentions the service authenticating itself by means of a certificate as well.
Hope this helps a bit
Marc
Related
MSDN for <serviceCertificate>says this
This configuration element specifies the settings used by
the client
to validate the certificate presented by the service using SSL
authentication.
MSDN for <identity> says this
In the handshake process between the client and service, the Windows
Communication Foundation (WCF) infrastructure will ensure that the
identity of the expected service matches the values of this element,
and thus can be authenticated.
As I understand, both these elements are used to authenticate service to the client.
Question: Could someone please elaborate and let me know the difference?
Thanks!
These are quite different.
As its name implies, the <identity> element is used by the client to identify a service, answering the question "Who are you?" It contains many child elements that can be used for this purpose - as there are many ways of identifying a service: certificate, SPN, UPN, etc.
<serviceCertificate> specifies an actual X.509 certificate used to authenticate a client or service, helping to answer the question "How can I be sure you are who you say you are?"
We have a HTTP endpoint where a form request is posted containing transaction data from a 3rd party https website.
We are investigating ways that our HTTP endpoint can contain code to check that the host that posted the request is the 3rd party website and no-one else (i.e. a hacker).
Is there any way our HTTP endpoint can authenticate with the website where the posted form request originated? Maybe by SSL Certificate Authentication?
Many thanks in advance.
To guarantee that the server on the other side is who they say they are the safest way is to have them use an SSL Certificate. If the they also need to trust who you are then each side should have their own SSL Certificate.
The IP Range solution provided in the comment could be a possible hack but it's quite brittle and it couldn't be applied in a very serious environment.
The Shared Key solution will work and it's reliable but you have to change keys from time to time depending on the volume of traffic between the two servers.
Hope this helps.
It might be better to use message-level security instead of transport-level security (SSL/TLS).
The third party website would sign the message using its certificate (or to be precise, using the private key matching its certificate), and your website would verify this signature.
This could allow for that message to be relayed by the user's browser, without needing a direct connection between the two servers.
This sort of mechanism already exists in the Identity Management world, for example with SAML and Shibboleth. (You can still have direct connections between the servers to get additional information too.)
I want to migrate an existing On Premise WCF service to Windows azure without asking clients to change anything in thier application like endpoint URL, certificate etc.
PLease let me know if this can be done?
In principal - yes.
The Endpoint Url is dependant on you controlling the domain and forwarding the URL over to Azure (for us, we use a CNAME redirect to the Azure URL). More details here.
For the certificate, as long as you've got an exportable version of the certificate with a Private Key, it should be a matter of uploading the certificate to the server that matches the endpoint URL. More details here.
So, all in all (with these changes in place) it's just a matter of uploading the certificate, redirecting to over to Azure and then letting DNS do its thing. If in doubt, certificates are buttons to purchase, so use that for testing purposes to prove the concept.
I'm confused about what the identity element on a client endpoint really does. I've understood that a identity dns value like is supposed to tell WCF to assert that the service's certificate is issued to myserver.local. And that this should allow me to point the endpoint address to https://localhost/MyService.svc instead of https://myserver.local/MyService.svc.
But this fails I don't understand why. I have myserver.local pointing to 127.0.0.1 in my host file and I have self-created certificate issued to myserver.local. It works fine with myserver.local but when I change the endpoint address to localhost it stops working because it "can't establish a SSL/TLS trust".
Can anyone explain why?
Thanks
If you want to know what the WCF Identity DNS value is for, and what to put in it, see this question:
WCF client endpoint identity - configuration question
It helped me to understand what it's for.
I have binded my IIS7 with a third party 'Server certificate' (Not issued by my server).
I have deployed a secured WCF service on this server with Transport security.
When i try to consume this service, it only accepts those client certificates which are issued by my server (made using makecert). The third party client certificates just don't work here.
To my knowledge it should accept them as they are issued by the same CA!!
Any idea on how to make it work?
Seeing your configuration would help, anyway it seems that the WCF service (not IIS itself) is not configured to use your third party certificate, thus requesting your clients to have a client-side certificate issued by your server.
Take a look at this guide, it helped me a lot when I had to deal with this:
Link