I have some domain names that I use for testing out Azure features, write some blogs and other fun stuff. I find myself needing, wanting to use HTTPS and using the instructions I wrote some time ago, see below, to create the certificate is long and tedious. I had an epiphany which lead me to use/create a single SAN certificate for all of my domain instead of a single one for each domain.
In the previous links I used an older utility called MAKECERT which is/was part of the Windows XP Server Tools package and may be hard to get your hands on these days. Therefore, I am going to start using the PowerShell cmdlet called: New-SelfSignedCertificate described here. It seems very capable of fulfilling my testing needs after quickly looking over all the possible parameters it supports.
Before I start I want to quickly touch on the differences between 3 different certificate types.
- Wildcard certificate
- Standard certificate
- Subject Alternative Name certificate (SAN)
A wildcard certificate is a certificate that will support any subdomain for a given domain, for example, *.contoso.com would support the following subdomains:
- admin.contoso.com, blog.contoso.com, github.contoso.com, www.contoso.com, etc…
A wildcard certificate would not work for a naked domain, where there is no subdomain provided, for example: contoso.com
A wildcard certificate would only work at the depth of one subdomain and you wouldn’t be able to get a wildcard certificate like *.*.contoso.com, at least I have never seen one like that. This means that a wildcard certificate of *.contoso.com would not work for:
- login.admin.contoso.com, msdn.blog.contoso.com, etc…
What I refer to as a standard certificate is an SSL certificate that is issued to a single domain like contoso.com. It is valid only for a single domain or subdomain name and only one.
A Subject Alternative Name certificate is one which can include many different domains, whether they are naked, subdomain, sub-subdomain and the domains within them do not need to have any relationship with each other for example *.contoso.com and www.microsoft.com can both be included in the same SAN certificate.
Now that tis is clear, let’s create a self-signed SAN certificate for testing. I specifically call out ‘for testing’ because you would want to get a certificate from a Certificate Authority for running a real business where this encryption is needed.
Execute the following to create the SAN self-signed certificate.
New-SelfSignedCertificate -CertStoreLocation Cert:\LocalMachine\My -DnsName "*.contoso.com, contoso.com, secure.login.contoso.com"
Notice that I include a wildcard, naked and sub-subdomain, see Figure 1.
Figure 1, create a self-signed SAN certificate
You can look into CERTMGR for the Local Machine and see the certificate you just created, Figure 2.
Figure 2, use Certificate Manager to view the SAN certificate details
When you open the details of the certificate you will get a message “This CA Root certificate is not trusted. To enable trust, install this certificate in the Trusted Root Certification Authorities store”. To get ride of this issue, you need to export the certificate you just created, I describe how to do this here, see section “Export the certificate as a .PFX file, include all properties and private key” and then import it into the “Trusted Root Certification Authorities”, you can see that in Figure 2 above. Expand Trusted Root Certification Authorities –> right-click Certificates –> All Tasks –> Import. After importing the PFX you will see details as shown in Figure 3.
Figure 3, viewing the properties of a SAN Subject Alternative Name SSL certificate TLS SAN
I exported the certificates and I was able to configure them for an Azure App Service. I do get a warning that the certificate is not a valid one, but this is expected because it is for testing only. You would not be able to configure the SSL certificate for Contoso on Azure because you do not own the domain, Azure will check that the domain is configured for the App Service and only list or allow certificates to be configured for a domain that is registered to the web site.