Popular Posts | 10 Min Read
Posted on: Thursday September 17, 2020Reading Time: 10 minutes
The capability of adding free SSL certificates to web apps on Azure is one of the most significant announcements made by Microsoft during Ignite 2019. Now developers can quickly secure their web apps without spending hundreds of dollars in third-parties for SSL certificates.
Let’s have a trial of this new capability and analyze how it turns out.
Test web app setup using Azure CLI
For testing this capability, a web app is required, along with a resource group to initiate. Getting in Azure Cloud Shell from Azure Portal is possible.
Need to create a new resource group first:
az group make –name free-SSL –location uaenorth
Now a new resource group identified as free-SSL is created. Now there is a requirement for web app plans to input web app resources and define any web app features. For building an app plan, the following input must be entered in Azure Cloud Shell:
az app service plan create –name free-SSL-app-plan –is-Linux –location uaenorth –sku B1 –resource-group free-ssl
We recommend a Linux-hosted app plan where SKU is B1. It’s a budgeted pricing tier, allowing SSL to be enabled.
Now we require space for an existing web app:
az webapp create –name free-ssl-web app –plan free-ssl-app-plan –resource-group free-ssl –runtime “DOTNETCORE|Latest”
Remember that runtime must be specified for a web app. A difference occurs whenever you’re continuing the web app on a Linux-based app plan or a Windows-based app plan. Figure out supported app plans by running:
az webapp list-runtimes [–linux]
Here we have a web app along with a corresponding app plan continued:
For identification of web app works, recall curl.exe from Windows 10 command line:
Preparing DNS for the web app and free SSL certificate
For having a check-out of free SSL certificate capability, a custom domain and a sub-domain are mandatory. The app’s present DNS entry will be free-ssl-webapp.azurewebsites.net since putting an SSL certificate for something.azurewebsites.net is not possible. The present option for adding two entries in DNS would be www., and the actual domain.
We’ve selected a new sub-domain called free-ssl under my existing uaedriving.com domain. Since the zone is under hosting from Azure DNS, concern remains focused on setting a new record through Azure Portal. Using Azure CLI is imperative here by scripting like Web App > Custom domains to be added in the domain for web apps:
For validating a free SSL either through CNAME record in uaedriving.com or a regular record. I prefer using a temporary, CNAME entry, and integrate the proposed entry into my freessl.jussiroine.com recordset:
Coming back to a custom domain view for a web app, trigger Validate’s option to verify when the change is visible for Azure:
Once Hostname availability and Domain ownership turn green, you’re right. Click Add custom domain to complete the change.
Azure Portal kindly suggests now would be a great time to add those missing SSL certificates:
Adding a free SSL certificate for the web app
Finally, we proceed to add the SSL certificate. Just follow the process – Click Web App > TLS/SSL settings. In the top navigation bar, trigger the option Private Key Certificates (.pfx):
Trigger the option Create App Service Managed Certificate in available new view:
Just about to finish! Select the sub-domain from the dropdown:
Now click on Create and remain patient for the process to complete then you’ll quickly see a new private key certificate:
You can easily verify that certificate is genuine, in details:
In Web App > TLS/SSL Settings, go for Add TLS/SSL Binding, and private certificate thumbprint and select the custom domain:
Testing the new SSL certificate
For testing the new SSL certificate with your website, open the browser in Private/Incognito mode to check the newly uploaded SSL certificate rather than a cached version of the old certificate.
When the site load finishes, then click on the padlock to verify whether the new SSL certificate is applied and correct:
In Azure, free SSL certificates have is an excellent new capability. It’s easy to configure, and certifications have the option of auto-renew, that’s like an additional benefit.
But their naked domains are not supported, unfortunately, and usually referred to as apex domains. For example, https://uaedriving.com cannot be secured, but https://[subdomain].uaedrivng.com can be. It indicates that individual blog pages can be easily secured.
Since a SAN (Subject Alternate Name) cannot be specified for the certificate, then using the same certificate for securing multiple identities of a web app is not possible along with no allowance for Wildcard certificates.
Let us assume these omissions would be added in the coming times. The capacity is good as of now if you are having subdomains and no plans for opting apex/naked domains.