Upgrading or Replacing your SSL certificate for an Azure Cloud Service application

If you’ve been operating an application as an Azure Cloud Service for a year or two, then you are probably due to renew or upgrade your SSL certificate. People move on, and contractor rates go up. You may not be the person that installed the original SSL cert or may not have documentation on how to install a new cert. The process is simple and takes only an hour once you’ve acquired your new certificate.

  1. Downloaded the new certificate from your certificate provider
    Each provider is different in how they will deliver the certificates. GoDaddy will have you select your server type (e.g. IIS6, IIS7, Tomcat, Apache) before downloading the certificate. When you requested the certificate from your provider, you had to use one of these servers to generate the CSR (certificate signing request). You will be receiving a CRT (web server certificate) from your provider. It’s important to choose the right server type so the CRT can be imported. If you’re deploying to Azure, then you’ll probably choose IIS7 like I did. Download the cert files (or zip file) and save it somewhere safe from prying eyes.

    NOTE: You will likely also receive some intermediate certificates. These have much longer lifespans than a 1-2 year SSL certificate. You’ll follow your provider’s instructions to install these later, if necessary.

  2. Complete the certificate request on IIS
    If you received intermediate certificates from your provider, now is the time to do so. This will ensure that you have a full certification path. Follow your provider’s instructions for this. These intermediate certificates have lifespans of up to 10-20 years, so if the thumbprint is the same no action will be necessary. You can check this by double-clicking the certificate and checking the thumbprint on the details tab. Compare that value to what was previously uploaded to Azure under Cloud Services – <Your Cloud Service> – Certificates tab. Any previously uploaded intermediate certificates will appear here as well as your existing SSL certificate.

    In IIS7 on your server, VM, developer workstation, click on Server Certificates. In the Actions pane on the right, click Complete Certificate Request. Browse to find the name of the CRT file you downloaded in the previous step. Type a friendly name like “*.my-domain.com” and click OK. If the import is successful, you’ll see your certificate appear in the list on the Server Certificates screen in IIS.

  3. Export the certificate as a PFX file
    Open MMC and add the snap-in to work with the Local Machine certificate stores appearing as Certificates (Local Computer). Find your certificate in the Personal \ Certificates store and look for the friendly name you entered in the previous step. Right-click on the certificate, choose All Tasks and then Export to open the Certificate Export Wizard. Follow the wizard, choosing Yes, export the private key and Include all certificates in the certification path if possible options. Type a good password and choose a file path to export the PFX file. For future-you’s sake, name the file with a .pfx extension. When the wizard completes, your PFX file will be ready for use.

    Before you leave the certificate manager (MMC), double-click the certificate to open it and copy the thumbprint from the Details tab. You’ll need the thumbprint in later steps.

  4. Upload the PFX and intermediate certificates to Azure
    Now that you have both certificates, navigate to the uploaded to the Azure Management Portal, and click on Cloud Services. Find the desired cloud service in the list, and click on it to select it. Click on the Certificates tab, and then click the Upload button in the bottom menu. Browse to find your PFX file, and type the password. Click the OK button.
  5. Change the service configuration to use the new thumbprint
    Open your application’s solution, and open the ServiceConfiguration.Cloud.cscfg file in the Azure hosting project. Find the existing SSL certificate under <Certificates>. Paste in your new thumbprint, making to sure it’s all uppercase with no spaces. If your thumbprintAlgorithm has changed, change that value in the config file as well.
  6. Deploy your app to Staging
    Now that your certificate is on Azure and your application has been updated, it’s time to deploy to staging, Once your deployed is complete and your staging environment status returns to “Running”, try out the Staging environment using the HTTPS version of the Site URL seen in the Azure Management Portal. Using Chrome, find the certificate information by clicking on the lock symbol in the address bar and then click the Connection tab and then Certificate Information.
    It’s expected that it is complaining at this point because we aren’t using the intended domain name, staging uses <random>.cloudapp.net. Check that the end date, thumbprint, name, and other properties are what you expect to see.
  7. Swap VIPs
    Once you’re satisfied that the Staging environment is a good build and that the certificate is correctly assigned, swap the staging and production environments. When completed (< 30 seconds), check out your application using the HTTPS endpoint and domain name. You should see the lock in the address bar, and make sure to check the properties (e.g. expiration date) again.

That’s it. Party on!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.