I have the following (planned) set-up:
Website: domain.com (Wordpress page hosted on GoDaddy, Standard SSL
certificate enabled)
API: x.domain.com pointing to x.azurewebsites.net via CNAME entry
Client 1: a.x.domain.com (client 1) pointing to a.azurewebsites.net via CNAME entry
Client 2: b.x.domain.com (client 2) pointing to b.azurewebsites.net via CNAME entry
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?
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.
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.
https://www.ssllabs.com/ssltest/analyze.html?d=recruit.equitysim.ai
Situation:
A client needs to access our site over a secure connection but is unable to do so because of a problem with our certificate.
We purchased a wildcard certificate and set it up as per the documentation. If you notice in the provided link, our certificate is trusted.
We are using the Azure App Service to host our website on a paid level that includes custom domain and SSL support.
Problem:
According to the test, it appears that Microsoft's SSL certificate is not trusted - alternative names mismatch (See Certificate #2). We believe this to be the reason why our client is unable to access our site.
Any thoughts on the matter? We know it isn't an SNI problem because we have another site that is hosted on a VM that also requires SNI support and they can visit that site just fine.
I'm building an ASP.NET MVC website to be hosted as a shared Azure website with custom domain name.
For the backend portion of the site (for specific users only) I need a login form and from that point on all traffic should be SSL encrypted. However I don't have a custom certificate and would like to avoid that extra cost.
I noticed that free websites already serve over HTTPS with a wildcard certificate for *.azurewbesites.net. Is that "free" azurewebsites.net-address also available for shared websites with custom domain(s) so I can simply redirect all "pages" that require authentication via the https://xyz.azurewebsites.net address? I'm aware that would be a cross-domain redirect which is visible to the end-user but that is not an issue since it's only a select group of users...
Yes, using the *.azurewebsites.net domain is your only option to have HTTPS without extra cost. The domain is always available, even if you use a custom domain, because it's used for a few additional services (like your repo, remote console, ...).
If I create an azure website let's assume: myname.azurewebsites.net, I can access this by using http (http://myname.azurewebsites.net) or https (https://myname.azurewebsites.net).
What does this mean? Did I understood it right that basically I don't need an SSL certificate as it has one by default?
I need to build a web service that needs to use SSL. Therefore do I need to buy an ssl certificate and custom domain (not important)? I don't need a custom domain and the default one works fine for me. So can I use my service over SSL provided by Azure: https://myname.azurewebsites.net (is a wildcard certificate)?
If you need to build a web service that needs to use SSL I highly suggest that you use your own domain and your own SSL certificate (buy one) if you are going in production with it. If you just test/play around - than you can safely use the default provided one.
And you are correct about default provided one - you get a (free) SSL for your azure web site as long as it is only bound to the default XXX.azurewebsites.net domain. However the certificate you get there is a wildcard certificate issued to *.azurewebsites.net. I would not use it if I have to go for a production service!
If you are to use SSL features of Azure Web Sites with your own domain and certificate, check out the Pricing and requirement pages. There are important things to note!
I'll admit i am very new to web app development and have primarily developed offline. I am developing a facebook application and have decided to give windows azure a shot at being my host.
Facebook requires SSL to use and of course on my development machine this works fine, but i do not have my own SSL certificate. In order to have a custom SSL certificate I need to upgrade my azure subscription to get a custom domain and be able to upload my own custom SSL certificate.
Is there any alternative to get my site to allow SSL (https) requests during my development process because paying for a custom SSL, domain and reserved azure instance in an application during the initial build process seems to be a needless expense.
Windows Azure Web Sites is a prime candidate for Facebook application development. If you use the base domain mysite.azurewebsites.net you have SSL without needing your custom domain.
The reason for this being the azurewebsites.net domain has a wild card certificate in place.