Hope my question is clear!
I have created a WCF Service and have implemented all necessary work for SSL implementation.
From IIS to Web.config
I am able to accessing Service with following URL successfully on browser from my own PC.
https://mycomputername/wcfService.svc
but How can I access it using my IP-Address e.g:
https://192.x.x.x/wcfService.svc
Actually I have to access the web service from another PC with in my network.
The SSL certificate will be associated with a domain name, not with an IP address.
So you will have to customize how to accept the SSL certificate. If you have a .NET client, you can use ServicePointManager.ServerCertificateValidationCallback and return true to accept any certificate.
Related: How to ignore the certificate check when ssl
Related
It's been a week already and I'm still not fully comfortable with implementing ASP.NET Membership Provider with WCF. I'm wondering:
We already have a website which is running under HTTPS protocol. We are working on a new application which will have a WCF service and is going to replace our old application (with HTTPS). Now my question is, since we already have a secured website, do I have to get another certificate just for the WCF service?
If yes, then do I have to get certificates for clients as well? (As I was looking on the web, most of the answers I found were "yes".)
If no, can I use the existing certificate to authenticate my service?
To answer your 2nd question, you only need client certificates if you want your WCF service to support mutual (2-way) SSL authentication, in which both the server and client sides are authenticated by their respective certificates.
Refer to this question for further information on mutual ssl and wcf.
how to implement 2-way SSL certificate for WCF
You have to have 1 SSL Certificate per domain unless you purchase a wildcard certificate. So, if your current SSL Certificate is for subdomain.mydomain.com and you want to host the WCF service at anothersubdomain.mydomain.com (or even www.anotherdomain.com), then you'll need another certificate. If this is something that would happen fairly frequently, then I'd suggest you purchase a *.mydomain.com SSL certificate.
Another option would be to host the WCF service under the current subdomain with a URL like subdomain.mydomain.com\myservice\service.svc.
I can't answer your second question but I doubt you are using client side certificates.
Here's a link to a Beginner's guide on SSL Certificates.
We'd like to configure Transport Security (SSL) with Client Certificate for our WCF Service (basicHttpBinding) which is used only by Company X as a client of our service.
From our side, we have 2 load-balanced servers and from their side there is only 1 server.
On the 3 servers just mentioned, we have installed the same Root Certificate Authority which would be used to issue other certificates.
There are lots of confusion on how to configure this with WCF and where to install which certificates?
1) How many other certificates we should be issuing and to be installed where?
Should Company X issue a certificate as well?
Which certificates should be installed on our 2 Servers and which ones on their Server?
We should be trusting their server so I'd guess we'd require them to install a Client Certificate, right? Who and from where this certificate will be issued?
From the service side, how to configure WCF to trust this client certificate when received?
They should be trusting our 2 servers, how does this work?
2) What is the purpose of
<serviceCertificate>
and should we adding it to our config? Should the Company X add it to their end?
I've read the purpose is "to authenticate/identify the service to the client". I'd guess this means that we only need to install these certificates on our servers and they shouldn't be installed on the client's server.
Does it mean that it is the same as ssl?
We have hosted the WCF Service on IIS and we have also configured SSL via IIS. Does it mean we don't have to add
<serviceCertificate>
on our WCF config then?
3)
<clientCertificate>
I've read the purpose is to identify the client to the service therefore I'd guess it's something that should be installed on the Client's Machine certainly.
Who will issue this certificate? The Root Certificate Authority on our servers or on theirs?
Should this certificate be installed on our both Servers as well? or just on their side?
From our service side, how are we going to trust this client certificate? Any web.config settings or?
Many thanks,
I have a web service and I want to call it from https. What is the solution?
This work for http.
Since I have a pretty good background in server setup, I will try and tackle this question.
First off, you need to set up SSL on your website. This involves buying a SSL Certificate or self signing one. Once you have a SSL certificate you need to set up your server to use it and serve your website through SSL.
As for you web code, the service you are hosting will work just fine under SSL as without. You will just have to change how you call it to use https:// instead of http://.
If you are trying to secure sensitive data you may want to set up your web server to redirect all non SSL requests to the the same path but under SSL by changing http:// in the path to https://. Any decent server administrator should know how to do this.
We have Windows Service with tcp binding. It has a transport security mode and client credential type is Windows. Service is within a domain.
Now we want to make calls to this service from the ASP.NET application running on IIS which is not part of the domain. We don't need user impersonation. What is the most secure way to enable this sort of communication?
This is a pretty standard situation: Web server is in DMZ and I would like to know how to set a secure communication with WCF backend services.
I expect that it will not work. You cannot use Windows client credential type if you want to consume the service outside of your domain. You must use Certificate (or None but it means no authentication).
The difference is that Windows client credentials will create stream secured with SSPI whereas Certificate and None client credentials will create stream secured with SSL certificate. In case of Certificate client credentials each client will be identified by its own certificate (= you need one for your IIS server).
Here is a scenario:
Desktop application
Installed from the web
Needs to call a WCF webservice
Transferred data needs to be encrypted from Client to Server and Server to Client
Is there a well understood solution for this that is:
Secure
Easy to manage and deploy
I guess what this comes down to firstly is whether https encryption happens in both directions... Does it? Or do you need mutual authentication for that?
Try using HTTP over SSL
HTTPS is what you're after - it does provide end-to-end encryption (client-to-server and server-to-client).
So long as you can generate and install a server certificate, and be sure that your clients 'trust' the issuing authority of your certificate, then you're good to go. Note that this is not mutual authentication - your clients know that they have contacted the correct server, but the server does not know who has contacted it.
It can offer mutual authentication through the use of client-side certificates, but I would argue that does not fall under the 'easy to deploy' requirement.
HTTPS works...
I was confusing Encryption with Authentication and they are two different things. Simple Https which is the most common only authenticates the server to the client which is sufficient in many cases. An additional step (where the client also has a certificate) can be required to authenticate the client to the server but this is not required. In both scenarios, data with Https is encrypted from both the server to the client and client to the server using a session key once the SSL handshake has been completed. This is all described here:
Description of the Secure Sockets Layer (SSL) Handshake