Introduction
Information from websites and web services play an essential role in our daily life. To secure communication with Hypertext Transfer Protocol Secure (HTTPS), a valid certificate is therefore a must for every website or web service. Then, the communication for establishing an encrypted link between a server and a client – typically a web server and a browser – is done via Secure Sockets Layer (SSL). If the client trusts the SSL certificate, the web server sends back a digitally signed acknowledgement to start an SSL encrypted session between the user or an application and the server.
SSL certificates are usually only valid for one year or for a few years. For Administrators this means that they must exchange the certificates again and again. Furthermore, the admins must keep an overview of all services that use the certificates. The good news here is that administrators can benefit from using Azure services. This article shows how the use of rotating certificates with Azure Key Vault and Azure App Services works. As soon as the SSL certificates are uploaded in Key Vault and set up in the App Services, they can be used automatically in all App Services by renewing them at a single point.
My scenario and the goal
We had such a scenario in my organization. My company runs many websites with an SSL certificate through different Azure subscriptions. It´s a product offered as Software-as-a-Service solution with many subdomains, such as org1.product.com, org2.product.com and so on. This environment has grown historically and the existing certificate was about to expire. So, we needed a solution that would make changing the certificate easier in the future, ideally from a central location.
Thankfully, Azure provides such an environment. All websites were already running in various App Services. We just need to add an Azure Key Vault and reconfigure the SSL settings in the App Services. Storing credentials, SSL certificates, connection strings and other secrets in Azure Key Vault is recommended for every software project in the (Azure) cloud. So, here´s the How-To scenario with a sample to guide you through the process step by step.
Create an Azure Key Vault
The Key Vault is the store for secrets and SSL certificates. We can create that resource in the Azure portal. To create the resource, we select any subscription in our Azure AD, the resource group, the key vault name, the region, the pricing tier, and additional options and click Review + create as follows.
Once the deployment of the Key Vault is complete, we can upload the certificate.
Upload the certificate
We need the certificate as pfx file. The pfx file contains the public key file, the SSL certificate file, and the associated private key file. To generate a CSR (certificate signing request) and to generate the pfx file from a cer file, we can use tools such as Open SSL or similar as described here. Once you have generated or downloaded the pfx file and the password, we can upload that certificate to the Azure Key Vault.
In the Key Vault, we open Certificates and click Generate/Import in the top menu. In our case, we already have a custom certificate in the correct format. So, we can select Import and enter a certificate name, and we upload the pfx file and the password and click Create as here.
After the successful import we see the certificate in the certificates list with its thumbprint, status, and the expiration date.
Add a system assigned managed identity in the App service
Then, we navigate to the website. In this sample, this is a generated HTML website that shall use our custom domain and our certificate. In the App Service menu we select the Identity. Here, we switch the Status of the System assigned managed identity to On and click Save.
When done, we see the Object ID of the system assigned identity. Here, it´s c31e… we will use that later.
Add an access policy
Back to the Azure Key Vault. We can define the rules for the access in the Access policies. By default, only the current user is owner and has all permissions. We open the Add Access Policy link. Here, we search for the Object ID and should find the website MSI. We select it in the Principal panel and click Select. As key permissions, we choose Get and Certificate permissions are set to Get. Also, for reading purposes of the website, we can select Get permissions for secrets as well if needed. Then we´re done and click the Add button. The following screenshot shows that configuration for the Access policy.
The new access policy is shown with its permissions in the Key Vault. The certificate can be used now from entitled apps. Now, let´s add the domain to the website. See Grant your app access to Key Vault for details.
Create a A-Record or a CName pointing to the App Service
To point a domain to a website, we use the DNS panel of our domain provider, analogously as here. A CNAME record is added to the DNS zone, pointing to our Azure website.
So, that domain points to our azurewebsites.net. Depending on the name servers, this should be available to clients in the next few minutes or within the next hour (default 1 hour TTL).
Add the custom domain to the App Service
In the Azure portal, back in the App Service, we add the custom domain by clicking the Add custom domain link. We enter the configured domain name and click Validate.
After the validation, we can Add the custom domain to our website binding. Our website can now be opened with http://mydomain. Just, the certificate is missing.
Deploy the certificate to an App Service
To assign a certificate, the pfx must be imported in the App Service TLS/SSL settings. We open the Import Key Vault Certificate here.
In the side panel, we select the Subscription, the Key Vault and the stored certificate and click Select.
We confirm with the Select button when done. After the import, the certificate is added to the App Service Plan. From my point of view, the link Import Key Vault Certificate is a little bit misleading since there´s a connection to the Key Vault that allows to use a newer version of the certificate automatically and it´s not only a one time operation. Anyway, here we go.
In this sample, we have uploaded a certificate that is about to expire soon. Azure detects that and informs with a Warning symbol. We will take care of that later.
We have to add the binding to the certificate now. Back in the Bindings section, we open the Add TLS/SSL Binding.
So we can select the domain, the certificate and the TLS/SSL Type SNI SSL. SNI SSL The type Server Name Indication allows that multiple website can be accessed together and can switch domains and share a server on TLS port 443, even if only one IP address is available (multiple domains per server IP address).
After clicking Add Binding, the App Service settings are saved. You should also select HTTPS Only On and TLS 1.2 as here.
Check the result with HTTPS
When opening the website with HTTPS, you will see the website using the certificate. The browser can show the certificate details.
So, this worked perfectly. But wait. The certificate is going to expire soon!
Renew the certificate
Since the certificate must be renewed, we can now use our Key Vault. First, organize a new certificate. We already did that and have a new pfx with a password. The new certificate is valid till 2022. In the Key Vault, we generate a New Version of the certificate.
Again, we import the new pfx with its password.
So now we have a new version of the certificate deployed. The old had a thumbprint F2DC. The new one´s thumbprint is starting with 2AA1 and it´s valid for two more years.
Cleanup App Service Plans and certificates
When managing (manually assigned) certificates in App Services, it´s usually a good idea to clean up. The Health Status symbols help to do so. Here, we found an old App Service Plan that needs to be cleaned (after any other bindings are deleted).
Check the new certificate
It takes some time until the new certificate is used in the website. It is updated through an Azure job in the background automatically that runs obviously once a day. In my tests, the certificate update was visible the next day. When refreshing the page then, we should see the new, updated certificate, as here.
Benefits of using Key Vault with App Services
To sum up, there are many benefits when using Key Vault to manage SSL certificates for one website or for multiple websites:
- The certificate is stored in a secure and central location which allows a simplified management
- The certificate can be easily renewed in this central location and the certificate rotation works by simply creating a new certificate version for all assigned websites
- Only permitted apps have a controlled access (We can specify permissions such as Get, List, Update, Create, Import, Delete, Recover, Backup, and Restore)
- This is a no-code solution that is easy to configure in the Azure portal
We have a lot of reasons to use this mechanism and I can highly recommend that process to automatically rotate SSL certificates to Azure Websites. I hope this walkthrough helps you to secure your own websites with custom SSL certificates and Azure Key Vault.
More resources
Find more resources about Azure Key Vault, and App Services here:
- What is Azure Key Vault?
- Grant your app access to Key Vault
- SSL termination with Key Vault certificates
- Add an SSL certificate in Azure App Service
- Renew certificate
- Set up Azure Key Vault with key rotation and auditing
- Generating a CSR on Windows using OpenSSL
- Deploying Azure Web App Certificate through Key Vault
- Secure your Custom Domains at no cost with App Service Managed Certificates (preview)
Collaboration means two-way communication!
Did you like this article? Are you interested in this topic? Would you like to share your knowledge and experience with the authors and other readers? Our #communityrocks group on Facebook is bringing everyone involved together: authors, editors and readers. Join us in sharing knowledge, asking questions and making suggestions. We would like to hear from you!
Join us on Facebook
Related Articles
Logic Apps vs. Power Automate – Simplified
In this article we are about to simplify – as much as we can – the task of when to use Power Automate and when to use Azure Logic Apps.
Collaboration can be like a dysfunctional relationship
What can be more collaborative than the principle of DevOps? The very word suggests a collaborative relationship between Operations and Developers.
How secure is the cloud anyway?
Cloud is very secure. But there is always a ‘but’. There are a few things we need to understand and consider when moving our data to the cloud.