Secure Communication Using Web Services
Author(s): Prem Kumar
Date written JAN/10/2011
Introduction
The purpose of this document is to guide the reader through setting up a web service in such a way that the data exchanged between the client and the web service will be authenticated, encrypted and secured. This guide will help the reader to configure a secure webservice with the help of Digital Certificates, which have become an industry standard for any type of data exchange during communication between two objects.
Traditionally; the authentication can be achieved, for calling a web service, with the help of userid and password. In this case the client of the webservice has to first pass the user-id and password. The webservice then validates the credentials and based on the validity of credential, it allows the caller for further communication. Note that in this case only authentication is achieved, but the further data exchange between client and web service will still not be encrypted and can be trapped and understood.
This guide will also tell you little bit of coding to be done in the calling client.
Below three steps are to be followed to achieve the above said configuration:
1. Digital Certificate procurement
When purchasing a digital certificate, ensure that the requirement is for authenticating both client and server.
Network or server engineer should extract the public key from the digital certificate which has been purchased from certificate authorities. (By default the digital certificate will have both private and public key)
Digital certificates vary in file format providing different functionalities. The well known formats are
· Base 64 encoded .Cer files
· DER encoded binary .Cer files
· Personal Information exchange .pfx files
2. Web Service set up:
Develop a .net 2.0 web service and deploy it under Microsoft Internet Information Server (IIS).
The server engineer should use the digital certificate which has only the public key in it after extraction. The engineer should configure the website (or a webservice) as a secured one. The site should be HTTPS enabled.
To enable the secure communication for a web site right click on that web site and click on the Properties and follow the steps as described in the below snap shots.
Enable the check box “Require secure channel (SSL). Accordingly select Client Certificate” group as per test or production environment.
Select “Require client certificates” if you are setting a webservice for production use, because in production you must not allow any one to authenticate themselves and to to use your web service’s functionalities without the certificate based authentication.
But, if you are setting up a web service for testing, you can start with the “Ignore client certificate” and then make the client code changes accordingly to simplify the test of client code, and then change the setting to “Accept client certificates” to check that the web service is working with both i.e. when client sends the certificate and when client don’t sends the same.
1. Web Service Client Configuration
Any caller (web service clients) of the web service should pass the same digital certificate whenever they make a call to the web service.
On the caller PC (Client PC, not web server), the same Public Key digital signature needs to be installed. Install the Public key in "Computer Account". DO NOT install the public key in other account.
The following C# code will use the digital certificate file kept at a file system location.
string CLIENT_CERT_PATH = @"F:\Certificates\client1_exportedCertifiacte.cer"
webServiceObject = new Infosys.sample.HelloWorldWebService();
webServiceObject ClientCertificates.Add(
X509Certificate.CreateFromCertFile(CLIENT_CERT_PATH)
);
To install the certificate file which is present at the location CLIENT_CERT_PATH. Type “MMC” in the RUN prompt. Admin access is required to use "Computer Account" in MMC.




The .Net client code will need the file system location where the public key (digital signature file) is registered. The client code needs to call this public key from file system. There are only 3 extra lines of code to pick up the public key from file system. The .NET frame work will then internally search the same public key in the Key STORE (Computer Account). If present, the web service will be called and it will work fine.
The code will work fine even if the public key is present only in file system but not in key STORE. In such a case, the application will go ahead and call the web service, however the web service (depending how web service HTTP site is configured), will throw an exception to the caller (web service client).
Scenario 1.
When web service is setup to ignore the client certificate
If the client sends or does not send the certificate, the client application will still be able to access the secure web site in either case.
Scenario 2
When web service is setup to required the client certificate
In this case, the webservice need to get the certificate from its caller, i.e. client application of the web service. The client application must pass the digital certificate.
Note: If you only loaded the certificate file from file system as per the above code snippets, but have not installed the same certificate file in certificate store, the .net based client application will compile and will make a call to the webservice without throwing any error. In this case the web service will reject the .net client’s call, because web service must need the certificate which was not by .net based client application, due to the simple reason that certificate is not present in certificate store.
The client gets error message similar like ”Not Authorized 4.4.x"
References
Web Link
NA, This is a project based experience. Nothing has been referenced....
Keywords
[Microsoft Windows 2003 Server IIS 6.0, .net 2.0 framework web service secure communication digital certificate]