Someone recently asked me at that last Silverlight UK User Group as to whether communication between Silverlight and a web service can be secured. Silverlight is a plug-in that runs in the context of the browser, and so only supports the HTTP protocol but this does include HTTPS too.

So first off, we’ll need to to add a service binding.. if you have a HTTPS service already setup, adding a service reference will do all the hard work for you otherwise you’ll need to specify:

        <binding name="MySecuredService"
          <security mode="Transport" /> 

It’s the security mode that is important, normally it is set to None for HTTP, however setting it to Transport turns on HTTPS.
Whenever we expose services for Silverlight applications, we need to define a cross-domain access policy that resides within the service’s website. If you are accessing a public web service, then you might have to check with the provider to ensure that there is the appropriate permissions set within this file since it can be configured to only allow access to the services from particular domains or protocols. Hopefully the cross-domain access policy is within your control, in which case a basic configuration is to have a crossdomain.xml file in the root of the domain hosting the service(s).

<?xml version="1.0" encoding="utf-8"?>
      <allow-from http-request-headers="*"
        <domain uri="*"/> 
        <domain uri="http://*"/> 
        <resource path="/" include-subpaths="true"/> 

The line of interest is <domain uri="http://*"/> which allows access to an HTTPS service from an HTTP application (normally this is omitted).

More details can be found on MSDN here.
Really, yes that’s it…
If you want to track the calls and information relayed between your Silverlight application and the HTTPS service, use Fiddler2 which has a filter option to trace and decrypt the HTTPS traffic.
However, what if you are writing your own HTTP web service? Visual Studio does not have a HTTPS enabled web server to debug against, so you’ll have to look into hosting your HTTP service from your local IIS instead. Setting up your IIS server for HTTPS depends upon a SSL certificate which forms the basis for the trust relationship between the server and any of the clients accessing the HTTPS hosted services.
SSL certificates are specific to domains, so trying to debug HTTP against localhost is not going to work. Getting round this is simple enough, just add an entry into your computer’s hosts file for the name of the domain you want the certificate to be setup against and match it against
Your hosts file can be found at “C:\Windows\System32\drivers\etc” and if you are editing the file in notepad, make sure that you do so as an administrator since it is a protected system file.
IIS7 allows you to create self-signed certificates which are fine for regular web content but not for services – mainly due to the fact that the certificate is valid but the browser will not immediately trust the certificate because it does not originate from a recognised certification authority. Thus you’ll be presented with the following error in your browser, for which a user can navigate past, but a service call cannot:
Certificate Error: Navigation Blocked
So, to create a your own certificate for HTTP web service testing we’ll have to dig out the IIS6 Resource Kit and use SelfSSL.
I’m going to create a specific website for my testing, so open your IIS Manager and create a new website but add the name of your domain into the hosts name (what you set in the hosts file), so that IIS will look at the host headers if a match, it will redirect to this site.
Add Website 

Now, take note of the the new website’s ID, you can find this out by clicking on the Sites node in IIS Manager. The reason why I point it out is because you may have many other websites running and the SSL certificate can only be set against one of these sites.

 Sites list

Open up a command prompt (as an administrator if you’ve got UAC turned on) and run up the SelfSSL command:

SelfSSL /N:CN=<your domain name> /V:<number of days till expiry>  /S:<site id>

thus following continuing my example:

SelfSSL / /V:365  /S:2

The command prompt will just state that a certificate was successfully assigned, but we can check this by looking at the Server Certificates panel in IIS Manager (click the Root node and then Server Certificates in the IIS section). Note that this is different to creating a self-signed certificate in the IIS7 Manager which creates a certificate issued by your computer’s name instead.

 Server Certificates

Although we have a self-signed certificate, it is still not trusted and we’ll get the following certificate error which can be overridden by the user when browsing to the site. However, we’re now in good stead, since we’ve a certificate issued by a domain name that can be configured to be be trusted.

Certificate Error: Navigation Blocked

So, going back to the Server Certificates panel, select the certificate just generated and click Export in the actions pane.

 Server Certificates

An export certificate dialog will appear and so fill in the destination for the certificate and a password (make it really secure if you want to use this for a live website). Note, give the destination file a pfx extension so that Windows recognises this as an exported certificate file.

 Export Certificate

Now, if this was a shared web server, you can pass the certificate to all those users that want to access the HTTPS services from the specified domain name. Open a command prompt (as an administrator if you have UAC enabled) and execute the pfx file. This will activate an install certificate wizard.

 Install Certificate

First step is just an introduction, the second specifies the certificate file we are importing:

 Certificate Import Wizard 1

The third step requires you to type in the password that was set for this certificate file, accept the defaults for the other options (as shown):

 Certificate Import Wizard 2

The fourth step is important. Normally, the “Automatically select” option is selected and to enable this trust across web pages and web services exposed by our secured server. If we did allow Windows to automatically select the certificate store it will pick a location for which only browsers can utilise the connection – not services. Thus, select the second option – “Place all certificates in the following store” and then click Browse.

Certificate Import Wizard 3

Be patient, the wizard may take a little while to open up the certificate stores. Tick the “Show physical stores” and then select “Trusted Root Certification Authorities”, and then “Local Computer”. Click OK.

Note: if you don’t see “Local Computer” you did not run the wizard as an administrator!

Select Certificate Store

The final step of the wizard is a confirmation for which clicking OK will add the certificate into the certificate store for this computer.

Wow.. look at that. Navigating to my default page did not ask me for a certificate… you’ll find the same for any web service calls no more un-trusted certificate warnings.

 Hello World Test 

Additionally, looking in the IE Options panel, on the Content tab, click Certificates:

 Internet Options

Cycle through the tabs till you find the Trusted Root Certification Authorities tab and somewhere in the list should be the certificate we imported.

 Certificate Store

This process of creating and installing a trusted self-signed certificate does not just apply to Silverlight testing, but is the normal process for adding a certificate to for any HTTPS website or web service testing.



This is a cross post from my EMC blog, mainly for backup duplicity and to aggregate some of my past postings. My EMC blog used to be under the Conchango brand but was acquired by EMC so I’ve also retrospectively refreshed some of the old links and maybe a tweak a bit of content too.
permalink to the original post here