I'm trying to implement transport level security for WCF services.
My application architecture is as follows:
WCF service is hosted as windows service in domainA.
Client is a WinForms application in DomainB.
Since it's a cross domain scenario, I have to use certificates for authenticating client and service so they can establish a secure connection.
My understanding is I need 3 certificates to achieve this:
Service certificate - authenticates the service to the client.
Should be installed in Local Machine --> Trusted Root Certificates store on a service machine.
Certificate authority - a certificate that can be used to issue user specific certificates. Where should this one be installed? Service or client machine?
User certificate.
Should be installed in Current User --> Trusted Root Certificate on a client machine.
I couldn't find any examples on the web that use certifcate authentication over tcp protocol.
I could only find https examples with services hosted in IIS.
Any reference to a tcp scenario is greatly appreciated.
Are my assumptions correct?
Where should I install the Certificate Authority certificate (item 2)?
Are there other, easier approaches besides using certificates to accomplish transport level security over tcp in a cross domain environments?
Thank you in advance.
Related
We have a web service (service A) that calls another intranet service (service B) using HttpWebRequest via HTTP. When we have tried to upgrade that intranet service (service B) to HTTPS, we have started to see The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel exception.
Can this be related to not having the certificate in Server Certificates on the server where service A is located?
I have found the following article, but it seems to be more related to the same issue on the desktop, not on the server.
Could not establish trust relationship for SSL/TLS secure channel -- SOAP
#mason's comment to my question helped resolve the problem. Indeed CA's certificate was not amongst trusted root certificates.
It's not in IIS. It would be in Windows certificate store. Start > Manage Computer Certificates. The CA probably needs to be in the Trusted Root Certification Authorities > Certificates folder.
I am facing the following issue.
1 - I have deployed WCF service with SSL enabled on remote IIS machine and trying to use it from my web client.The problem is my browser is not allowing this service to be called.Before using my web client i have to hit the service url from my browser directly and then allow the certificate.
2- Got suggestion from somewhere to export the certificate on the machine where WCF is deployed and include that certificate file in Trusted certificates group on my machine.After I did that I got same problem when tried to access web service from web client.So I hit the service url from browser and got the same page which needs me to trust the certificate with a different message that "You attempted to reach 111.121.196.226(ip address of the WCF machine), but instead you actually reached a server identifying itself as "WMSvc-domain" where "WMSvc-domain" is the value of "Issued To" field in the certificate.
I hope I have made myself clear.Waiting for suggestions.Thank you.
WMSvc-machinename is the IIS Windows Management Service which runs by default on 8172/tcp and is used for remotely managing iis. When installed the default is to create a self-signed certificate. That wouldn't trusted. It could be replaced with a "proper" CA signed cert through the Management Service icon in IIS Manager.
I want to find out how to set up a WCF service, which communicates with client via certificate over SSL (HTTPS) in a load balancer environment. The certificate is used for message exchanges.
Update
Below is current setup:
WCF 3.5 is used, but can be changed to ver 4 if required.
IIS7.5 and ASP.NET 3.5
certificate is installed on each IIS,
each WCF app is installed on each IIS,
certificate is issued to *.mydomainname.com, where my app is under myapp.mydomainname.com
does load balancer require certificate?
Goal
Client uses certificate to communicate with WCF service over HTTPS in load balancer.
Any idea would be very much appreciated!
Your site hosting the service must be exposed on domain name for example:
myapplication.enterprise.com
This configuration must be done on all application servers in the web farm (load balanced servers) = you must assign correct host header. You must request / create certificate for this domain name and install it (including private key) on all servers in the farm. You must configure your web sites on all servers to use this certificate. DNS record for the domain name must be configured to point to IP address of the load balancer.
Load balancing must be done on TCP level to maintain HTTPS between client and your servers. In this scenario load balanced environment should become completely transparent to client and load balancer will not need the certificate because it will only forward TCP connections and SSL tunnel will be created with the real web server.
I am trying to use SSL and certificates with a web service (IIS 7, Windows 2008, .NET framework 3.5 SP1). I followed the basic instructions (http://learn.iis.net/page.aspx/144/how-to-set-up-ssl-on-iis-7/) and was able to get the site running soon. However, I can only connect to it from a client if the client has the web server's certificate in its Trusted Root Certification Authorities/Certificates store. If I don't add the certificate on the client site, I get the error "Could not establish trust relationship for the SSL/TLS secure channel with authority" on trying to connect to the service from client.
That's the correct behavior if you're just using self-signed test certificates. In a public/production environment, your server's certificate would be issued by a common CA like GoDaddy or VeriSign, which you have to pay to obtain.
Most (client) machines already have a large list of updated CA in their trusted root such as GoDaddy, and so a server certificate signed by them for your site will validate as a valid certificate on most* machines (without you needing to provide your cert as a trusted root).
*Most, meaning that there are browsers & operating systems which may be missing (or need updates) on common certificate authorities in their trusted root store.
Where did you get this certificate? If it's not a child of one of the certificates in the root authority already I sure hope you didn't pay money for it. If you're generating them yourself this isn't surprising because nobody trusts your CA server.
I have some dedicated servers running ASP.NET applications over internet. All servers are fully trusted (all belongs to the same company) and need to communicate to each other in a secure way. They are not part of a domain or work group and should not be.
Each server acts as both client and server of some WCF services. These services are few (1-2 per server) and light (a little data is transferred on each call).
I can use self-signed SSL certificates or X509. I'm looking for some way to make sure nobody from internet can call a WCF service on a server. New server would be added in the future.
I read about WCF but now I'm confused, is it good idea to use self-signed SSL certificates or not (non self-signed is not an option at the moment), which binding to use, which security mode to use, which authentication method to use...
I need some hints to start (please provide a link to a sample.
I would use a certificate-based authentication where both client and server are authenticated.
To make things more secure, do not use self sign certificates.
If your company already have a certificate server: issue certificates to each of your server and specify as an authentication configuration that both client and services need to present a certificate issued by your certificate server.
WCF security is a big topic, but there are some other non-WCF specific ways you can secure the service:
Use IP SEC to secure the communication channel
Use IP whitelists to grant / deny access to the port that the WCF endpoints operate on
Use a VPN Solution (particularly convenient if your company already has a site to site VPN)