Multi-domain wildcard SSL mapping multiple Azure App Service apps

Question

I have the following (planned) set-up:

1. Website: domain.com (Wordpress page hosted on GoDaddy, Standard SSL certificate enabled)
2. API: x.domain.com pointing to x.azurewebsites.net via CNAME entry
3. Client 1: a.x.domain.com (client 1) pointing to a.azurewebsites.net via CNAME entry
4. Client 2: b.x.domain.com (client 2) pointing to b.azurewebsites.net via CNAME entry
5. Client 3: c.x.domain.com (client 3) pointing to c.azurewebsites.net via CNAME entry

Since Safari has a stricter cookie policy (compared to Chrome, FF, Edge), we'll need to host the API in the same domain and clients in the respective subdomains, hence the planned steps 2-5.

We have 4 (x,a,b,c) Azure (linux) app services running. Each one is split into a staging and production environment (same instance, different domains).

The CNAME aliases and mapping custom domains in the Azure Web App service already works. The A record IP still points to the Wordpress website.

The next step is to bind the necessary SSL certificates. Here, I've identified different options, but am not sure, which one will work and which one is the recommended/best option:

Option 1: The GoDaddy support recommended to buy 8 standard SSL certificates (4 services * 2 for staging & production). This sounds like overkill to me, and is probably the most expensive, albeit flexible, solution.

Option 2: We buy a second domain (e.g. domain2.com), run the API x there, and assign Clients 1-3 (a.domain2.com, b.domain2.com, c.domain2.com) as first-level subdomains. (2.1) In that case, can a single wildcard SSL certificate really be used in several Azure instances? (2.2) Since the strict Safari cookie policy requires the API to be a domain-level higher than the clients, we'd need a third domain (+ certificate) for staging (besides production)... Or could a multi-domain wildcard SSL certificate allow this scenario?

Option 3: In case the answer to Question 2.1 is "no", we might be able to merge the 4 Azure web apps into one Kubernetes cluster and then use 2 wildcard SSL certificate inside the same instance (1 staging, 1 production).

Option 4: I am successfully using Let's encrypt for several private websites, but am a bit hesitant to use them in a commercial service. Azure has an inofficial extension to manage and extend Let's encrypt certificates. Is this something that we should consider as well, and what are the disadvantages?

Personally, I think Option 2 would be the best since it wouldn't require our services to be reconfigured (like Option 3). Please keep in mind that the website (root domain) is not hosted on Azure; although if necessary, we could move it to Azure.

Or is there a 5th option I am missing?

Answer 1

There is an option you're missing.

Provided that x is static in your case then you could obtain a single wildcard certificate for *.x.domain.com.

GoDaddy will surely recommend purchasing four separate certificates, and to an extent I don't blame them. The appropriateness of using a wildcard certificate for multiple endpoints really depends on a number of factors. What one has to appreciate is the security concerns of encrypting client-server communications with the same key when there are multiple different servers, in so much that the scope of key compromise may broaden if using the certificate's private key on a number of different servers which have attack surfaces of various sizes and topographies. Compromise one server, the key is compromised for all.

In your case, you'll be using the certificate in Azure only, and so you have a common attack surface for all applications. It would therefore be okay to use a wildcard certificate.

If x were variable as well as the bottom level hostname you'd be out of luck. RFC 6125 requires certificate validating clients to assess the use of a wildcard at the leftmost (bottom-level) domain name portion only. Eg. *.x.domain.com is valid, but a.*.domain.com is not.

Let's Encrypt are sponsored by the some of the biggest players in the industry. If you're able to overcome the short validity period with automation then I would highly recommend them. They're now trusted by all major browsers and operating systems. I've had success with PowerShell automation hosting my DNS in Azure. If your root domain is with a third party you may want to consider creating a DNS zone for x.domain.com and creating NS records for the stub in your third-party DNS provider pointing to your Azure zone name servers.

Answer 2

Even though Architect Jamie posted a very helpful answer and I was ready to implement the Let's encrypt-approach, I just found out that Microsoft actually released a native option:

App Service Managed Certificates (preview) that provides a free certificate option for App Service hosted apps. Details can be found on the Microsoft Azure Docs.