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.
Recently I created a website in asp.net core and hosted in Azure Shared tier (non-secure). there is one feature on my website, get user address based on geolocation and autofill registration form.
Problem
getCurrentPosition() and watchPosition() no longer work on insecure origins (As of Chrome 50, the Geolocation API will only work on secure contexts such as HTTPS.)
The site is very small and I don't want to spend money on SSL certificate. (I can go with free SSL https://letsencrypt.org/)
Custom SSL certificate hosting only available on Azure Basic and above tier.
Is there any solution/workaround available?
Thanks,
Use Let's Encrypt (https://letsencrypt.org/) to get a certificate for free.
Sign up CloudFlare Free Plan and use their free SSL.
https://www.cloudflare.com/ssl/
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 am trying to consume the certificate uploaded in azure website(not webrole) in my web app using following config
<microsoft.identityModel>
<!-- Service Configuration -->
<service>
<serviceCertificate>
<certificateReference findValue="2696C50B72CB368AEB11DE3B23CD226252A1BFD" storeLocation="CurrentUser" storeName="My" x509FindType="FindByThumbprint"/>
</serviceCertificate>
<certificateValidation certificateValidationMode="None"/>
</service>
Code works fine on local system. But I am recieving error when deployed to azure website.
ID1024 The configuration property value is not valid
ID1025 Cannot find a unique certificate that matches the criteria
I then tried to browse all the certificates in my azure website(using code). But the certificate list does not contain my uploaded certificate.
Certificate is uploaded and can be seen in azure portal.
Custom domain is mapped and the uploaded certficiate is used against the domain.
But somehow my web app is unable to find the certificate. I tried all possible combination of StoreName and StoreLocation but in vain.
I think there may be some confusion on what the certificates you upload via the Configure tab for Websites are used for. Currently the certificates loaded there are ONLY used for SSL.
When looking at the little help icon next to the certificates section on the configure tab the tooltip states the following:
"This section lets you manage SSL certificates that you can bind to your custom domain names. Binding an SSL certificate to your custom domain name will allow your end users to access your site over HTTPS."
Windows Azure Web Sites exist at a process level, meaning that they can be started up on one machine but move around as the processes go up and down. If you aren't familiar with this I'd suggest reading up on how the hosting model works for Web Sites. Here is an article that covers it: Windows Azure Web Sites - A New Hosting Model for Windows Azure (full disclosure: I wrote the article).
Loading the certificate here I do not believe adds the certificate to any of the stores on the machines your web site runs on. Windows Azure would need to ensure that the cert is always on the machine the site is deployed to and since this is only at a process level and can change frequently (unless you are using standard) it doesn't make sense. The SSL certs are handled differently and as far as I know aren't really deployed to each machine.
As far as I know in order for you to load a certificate and use it you'll either need to look at a web role where loaded certs from the portal ARE placed into the store on the VM or look to see if you can load the certificate manually in code and ship the cert as content on your site (which seems a little less secure to me). I could just be overlooking an option though.
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.