IntroductionIn all development processes, you need to perform a security review in order to responsibly handle your user’s data . With my Windows Phone 7 application, the process turned into a huge decision and many incremental steps to handle. This blog post will enumerate how I took my unsecured WP7 app and corresponding Windows Azure website and secured them. This blog includes a detailed step-by-step of deploying a SSL certificate on Windows Azure.
- DNS Name Change: Mapped my subdomain (wazup.berryintl.com) to my Windows Azure subdomain (*.cloudapp.net) via a CName change to my DNS on Network Solutions.
- Cert Provider: Found an SSL Cert provider.
- Dev Box/IIS: Created the certificate request in the IIS Manager.
- Cert Provider: Since I was requesting a wildcard certificate to handle all subdomains as well, I received two files: one for the domain and one to handle the wildcard subdomains.
- Dev Box/Certificate Manager: The next part of the process involved added these two files to my local Certificate Manager and exporting a single file (*.pfx) that Windows Azure could read.
- Windows Azure: Uploaded the certificate to Windows Azure on the Hosted Service in the Certificates node. Once that was done, I grabbed the corresponding Thumbprint GUID.
- Dev Box/Visual Studio Azure Web Project: Added the certificate and an HTTPS endpoint to the project.
- Dev Box/Code Changes: Changed the web service to answer HTTPS calls only and changed the Windows Phone 7 app to call the web service with an HTTPS request.
- Dev Box/Visual Studio Azure Web Project: Created package.
- Windows Azure: Uploaded new package for testing.
A Note about Best PracticesWhile I agree best practices should always be followed, for this blog post I’m ignoring them.
Clear textDuring the in-house beta for my app, I stored username and password in Isolated Storage. These were passed to my web service (hosted on Windows Azure) as clear text. While both practices were convenient for me as a developer, they presented a problem when I got to the security design review.
Security Design ReviewDuring the final security design review for the 1.0 release, I realized through research, that isolated storage on the Windows Phone 7 wasn’t a secure environment for passwords. As a result, I decided to store the username on the phone as it was but not store the password. This means the customer has to enter the password every time. This might be an annoying step but considered the data being secured (Windows Azure deployment information), the need for security outweighed the risk.
Now that I didn’t have a security weakness in handling username and password on the phone, I realized that I was transmitting the data as clear text. The fear is that someone could perform a man-in-the-middle attack and the password would be compromised in transmission. So I purchased an SSL cert for the web service so that the conversation between the phone and the web service was completely private. Because of the number of steps involved, I wanted to detail the second step below.
Edit Network Solutions DNS CName for Domain To Azure NameThe first thing I needed to do was add a NAME to my DNS to translate between my marketing URL (wazup.berryintl.com) and it’s hosted location on Windows Azure (*.cloudapp.net). Because you purchase an SSL certificate for a specific domain name which you must own, and Microsoft owns the cloudapp.netdomain, I needed to host the site on a domain that I own.
Windows Phone 7 Cert Providers – GoDaddy.comNext, I needed to know where to go for an SSL certificate. After finding the list of SSL Root Certificates for Windows Phone, I picked GoDaddy.com since they are the cheapest and were running an even cheaper deal at the time. The User Interface for SSL certificates on GoDaddy.com is so terrible that I thought it was a scam. But after one call to a very polite and knowledgeable support guy, I realized I could get a certificate there for a web site that was hosted on Azure for a domain name I didn’t purchase via GoDaddy.com.
Generate the CSR file for Dev BoxThe next step is to generate the CSR file from my dev box. I had to install IIS on my dev box in order to this. Then I followed these instructions for generating my CSR for IIS 7.
I don’t do this very often so I tripped up on the STATE abbreviation. Make sure you type out your state. Don’t abbreviate! I also had to look up how to enter a wildcard domain name but found this helpful page. The WildCard SSL certificate allowed me to secure both the main domain name (berryintl.com) and all subdomains. You can use this CSR Decoder to make sure you did everything right.
Go back To GoDaddy.com to process CSRWith the CSR file, I went back to GoDaddy to process my request.
Once the CSR file validated, I had to wait for my company IT boss to receive an approval request email from GoDaddy. All he had to do was click on the link (or something relatively easy). Then I could download the certificate from GoDaddy for IIS 7. The download included two files since I’m doing a wildcard cert: one was for the domain name (berryintl.com) and the second file was for the intermediates.
Local Machine Certificate ManagerFor this step, I read these detailed instructions: Installing Your SSL On Microsoft IIS 7 . The point of this step is two-fold. I need to take the files that GoDaddy gave me and 1) turn them into something IIS 7 & Visual Studio 2010 understand for my local box and 2) put on Windows Azure for my web service deployment.
At the command line, I typed MMC (opening the console), added the Certificates snap-in, selected Computer Account, then Local Computer.
The two nodes I needed are Personal and Intermediate Certification Authorities. Starting with the Intermediate Certification Authorities. in the Certificates subdirectory, I imported the intermediates file.
In the Personal/Certificates, I imported the berryintl.com file.
Complete Certificate Request
Go back to IIS, and in the Actions panel, select Complete Certificate Request. You need to select the main certificate file and a friendly name.
Once the certificate process is complete, the cert should show up in the server certificates list.
Export Certificate *.PFC via MMC Certificate Manager with Private Key
Back in the Certificate Manager, select the domain name under Personal | Certificates. Right-click and choose Tasks | Export.
Choose to export the private key. This means the certificate can’t be installed without the password that created the certificate file (*.pfx).
In the next set of options, choose to include all certificates in the certification path if possible, and export the extended properties. This will handle the wildcard subdomains.
Windows Azure CertificateThe next step is to get the certificate from the dev box up to Windows Azure. Logon to Windows Azure, and select the hosted service you want to add the certificates to. The SSL certs are kept in a separate location from Management Certificates so make sure you don’t select Management Certificates. Select the Certificates node under the hosted service. It should be empty. On the top tool bar, select Add Certificate.
Select the *.pfx file and password from the last step. Once the certificate is loaded on Windows Azure, select the main domain certificate and copy the Thumprint GUID. You will need that for your Visual Studio project.
Visual Studio WebRoleOpen the Visual Studio Solution that has the Windows Azure web role. In the Solution Explorer, select the [Name].WebRole node under the Windows Azure Project node. Right click and select Properties.
On the Certificates tab, select Add Certificate. Enter the name, store location (Current User), store (My), and the thumbprint from Azure. These correspond to the location in the Certificate Manager on the local box.
On the Endpoints tab, select Add Endpoint. Make sure to set the protocol of https, port of 443, and SSL certificate name to your certificate name.
This change is saved in the ServiceConfiguration.cscfg and ServiceDefinition.csdef files under the Windows Azure Project node.
Change Server REST codeNext you need to change your REST web service methods to reflect that they can only be used via SSL. You do this by adding the [RequireHttps] attribute above the Method Definition. Build and test (but don’t package/deploy your web service).
Change WP7 App calling CodeChange all client calls to your REST API on Windows Azure to use https instead of http. Build and test.
*Check in to Source ControlMake sure to check in the two files from GoDaddy, the *.pfx file from the Certificate Manager, and a text file containing the password used with the *.pfx file. Also check in the Windows Azure Service Definition files in the Azure Project node, the REST Method code files, and the WP7 app code files.
[*Granted storing the certificate and the password in the same place creates a security risk. At this point, I think you understand they are dependent on each other and one is useless without the other. Please follow your own organization’s guidelines for securing such files.]
Package & Deploy to AzureThis next step turns off your production deployment for a small period of time. Make sure to do this at your lowest customer usage time.
Since you are changing the endpoint count from 1 (http) to 2 (http and https), Azure won’t let you use the Swap Vips feature. At this point, you need to stop and delete the staging deployment on Azure. Then publish (via Visual Studio) and upload your new version of your web service to Azure. If you have a deployment in staging (new with 2 end points) and production (old with one end point), you need to delete the production deployment, then promote the new deployment from staging to production.
Test your live production deployment.
If your Windows Phone 7 app is already in the Marketplace, but isn’t using the HTTPS web service calls, make sure you submit the new app and get it approved/released to the Marketplace before promoting the new HTTPS web service deployment.