Implementing HTTPS in a web role

A Microsoft Azure web role can be configured to expose an HTTPS endpoint for a website. This requires an X.509 public key certificate to be uploaded as a service certificate to the Cloud Service and the web role to be configured to use it.

The following steps are used to implement HTTPS for a web role:

• Acquire a public key certificate for the custom domain of the web role
• Upload the certificate to the Cloud Service
• Add the certificate to the web role configuration
• Configure the website endpoint to use the certificate

The use of HTTPS requires the website to be configured to use a public key certificate. It is not possible to acquire a public key certificate for the cloudapp.net domain as Microsoft owns this domain. Consequently, a custom domain must be used when exposing an HTTPS endpoint. The Providing a custom domain name for a Cloud Service recipe shows how to map a custom domain to the cloudapp.net domain. For production use, a Certification Authority (CA) should issue the certificate to ensure that its root certificate is widely available. For test purposes, a self-signed certificate is sufficient.

The certificate must be uploaded to the Cloud Service using either the Microsoft Azure Portal or the Microsoft Azure Service Management REST API. Note that this upload is to the Certificates section for the Cloud Service and not to the Management Certificates section for the Microsoft Azure subscription. As a service certificate must contain both public and private keys, it is uploaded as a password-protected PFX file.

The configuration for the certificate is split between the service definition file, ServiceDefinition.csdef, and the service configuration file, ServiceConfiguration.cscfg. The logical definition and deployment location of the certificate is specified in the service definition file. The thumbprint of the actual certificate is specified in the service configuration file so that the certificate can be renewed or replaced without redeploying the Cloud Service. In both cases, for each web role, there is a hierarchy that comprises a Certificates child to the WebRole element, which, in turn, includes a set of one or more Certificate elements, each referring to a specific certificate.

In this recipe, we'll learn how to implement HTTPS in a web role.

How to do it...

We are going to see how to implement an HTTPS endpoint in a web role only on the 443 port, using a test (self-signed) certificate.

The first stage is creating a test certificate and uploading it to the Cloud Service using the following steps:

1. Use the Server Certificates section of IIS 8 to create a self-signed certificate and give it a friendly name of www.myservice.com.

   Tip

   Though IIS is not the purpose of this book, remember to click on the Create Self-Signed Certificate link on the right-hand side pane, type the name in the friendly name textbox, and choose the store (Personal is the default one).

2. Open the Microsoft Management console by typing mmc in the Run windows of the Start menu, and use the certificate snap-in, specifying the local machine level.
3. In the Personal/Certificates branch, right-click on the certificate with the friendly name of www.myservice.com and navigate to All Tasks | Export to open the Certificate Export Wizard.
4. Complete the wizard by choosing to export the private key (and otherwise accepting default values) and providing a password and a location for the PFX file.
5. On the Microsoft Azure Portal, select the Certificates section for the Cloud Service and click on Add certificate.
6. Upload the public key certificate by providing the location for the PFX file and its password.

The next stage is configuring a Cloud Service to use the certificate. We can do this by performing the following steps:

1. Use Visual Studio to create an empty cloud project.
2. Add a web role to the project (accept the default name of WebRole1).
3. Right-click on the WebRole1 item under the Roles folder of the cloud project; then go to the Properties page and click on the Certificates tab.
4. Click on Add Certificate, provide a name, select a Store Location, and a Store Name.

   Tip

   For certificates at machine level in the personal store, choose LocalMachine and My for the Store Location and Store Name, respectively.

5. Click on the … icon to browse the store and look for the www.myservice.com certificate. Then confirm it.
6. Go to the Endpoints tab of the Properties page you are on.
7. Modify Endpoint1 (the default one) to listen on port 443.
8. Choose https as the protocol.
9. Specify the certificate declared at step 4 in the SSL Certificate Name.
10. Build the application and deploy it into the Cloud Service.

    Note

    The final stage is verifying that we can use HTTPS.

11. Use a browser to access the web role using HTTPS.
12. Choose to ignore the certificate error caused by our use of a test certificate, and view the certificate.

How it works...

From steps 1 to 6, we created and uploaded our test certificate. We need to export the certificate as a password-protected PFX file so that it contains both the public and private keys for the certificate.

In steps 7 and 8, we created a cloud project with a web role.

From steps 9 to 11, we specified the linkage between web role bindings and the certificate. In step 10, we specified the certificate store on each instance into which the Azure fabric deploys the certificate.

In step 13, we modified the default endpoint to listen as an HTTPS endpoint, using the certificate, on port 443. In step 15, we specified the certificate to the endpoint.

In step 16, we built the application and deployed it into the Cloud Service. We verified that we could use HTTPS in steps 17 and 18. We are using a test certificate for which there is no root certificate in the browser. This consequently causes the browser to issue a warning. For demonstration purposes, we ignored the error and looked at the certificate properties to confirm that it was the test certificate.

There's more...

We can use IIS to generate a Certificate Signing Request (CSR), which we can send to a CA. We do this by opening the Server Certificates section of IIS and clicking on Create Certificate Request. When generating the request, we specify the fully qualified domain name for the custom domain, for example, www.ourcustomdomain.com, in the Common Name field. After the CA issues the certificate, we click on the Complete Certificate Request in the Server Certificates section of IIS to import the certificate into the personal certificate store of the local machine level.

From there, we can upload and deploy the CA-issued certificate by starting at step 2 of the recipe.

Using makecert to create a test certificate

We can invoke the makecert command from the Visual Studio command prompt, as follows, to create a test certificate and install it in the personal branch of the local machine level of the certificate store:

C:\Users\Administrator>makecert -r -pe -sky exchange
-a sha1 -len 2048 -sr localmachine -ss my
-n "CN=www.ourservice.com"

The minimum required bit length for Azure is 2048, and this test certificate has a subject name of www.ourservice.com.