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.
Related
I want to create certification by App Service Managed Certificate.
I set these records
and it works correctly but when I want to create App Service Managed Certificates by Azure
I got a strange error
Failed to create App Service Managed Certificate for hostname. Click here for more details.
I try different CAA records and none of them works.
what should I do?
and if I want to use terraform it is stuck at creating the certificate
I use this template
Azure does not support the .ir domain.
Good news on App service managed certificate.
Yes, you heard correctly it became GA now and supports apex domain with a country code top-level domain (ccTLD).
Key Features:
Supports Apex domain.
Auto renewed.
Expired in 6 month.
Auto renew 45 days before expiration.
Automate using ARM template.
App Service Managed Certificate for apex domain will take a bit longer to create than for sub-domain because it uses a different validation method.
Not exportable.
I hope this will help you in securing your environment.
Maybe the tutorial you need is this:
map-a-cname-record
Create a free certificate
I had seen this error before, and solve it by the steps below:
Check the CNAME records. Map a subdomain to the app's default domain name needs two records: CNAME record and TXT record.
Make sure you enabled the CNAME record mapping in Azure .
Clear the records you don't need, like the CAA records, because wildcard certificatesis not support for creating a free certificate. Take care of the limitations.
It may takes a while for this configuration to take effect.
App Service Managed Certificate is still in Preview, there are some limitations with this (as of today), kindly check them below.
It's a private certificate to use if you just need to secure your www custom domain or any non-naked domain in App Service.
The free certificate is issued by DigiCert. For some top-level domains, you must explicitly allow DigiCert as a certificate issuer by creating a CAA domain record with the value: 0 issue digicert.com.
The free certificate comes with the following limitations:
Does not support wildcard certificates.
Does not support naked domains.
Is not exportable.
Is not supported on App Service Environment (ASE)
Does not support A records. For example, automatic renewal doesn't work with A records.
Kindly see the different between App Service Certificate and App Service Managed Certificate.
https://microsoft.github.io/AzureTipsAndTricks/blog/tip259.html
Checkout this documentation for more details.
I wonder how exactly the https/ssl works on Azure when i have a shared plan. Microsoft states that i need at least basic plan to have SSL. When i try to access my site over "https://" protocol, apparently it works, and the browsers (I tested with Opera and Chrome) states that i have a secure connection.
Do you know how is this works? I have SSL even with shared plan, but it must be the certificate of the azurewebsites.net domain, and I just can't use my own?
On shared plan you can set a custom domain name but you cannot upload a custom SSL certificate. So you have to remain on the generic certificate *.azurewebsites.net that only matches yoursite.azurewebsites.net but not your custom domain name.
I have several (4) web apps running on Azure: 3 of them require very little processing power, thus, they had been running
on a Free plan; while the other one is meant for final users which means a higher load and a needs for a custom domain and SSL certificate.
SSL certificate was correctly configured (https://azure.microsoft.com/en-us/documentation/articles/web-sites-purchase-ssl-web-site/) and is working as expected.
However, we noticed all of the other sites are now importing this SSL certificate as opposed to the one offered by default by Azure (the one for *.azurewebsites.net sites);
this has caused all of our Free sites to move to the Basic tier automatically. We are the unable to set them to Free again, as an error message states Free does not support
our custom SSL certificate for our custom domain.
Notice that our custom domain is in no way associated with any of the (3) Free sites but just the one that needs it.
Also, when going to SSL cert options in our Free sites, we cannot remove the custom SSL cert, as it states the site requires at least one of them, and custom one is the only one.
When creating a new site, this custom SSL will be automatically imported as well.
What should we do so the Free sites make use of the default *.azurewebsites.net SSL cert instead of the custom one, so we can then get back these sites to the Free plan?
Thank you for your help.
1.Root cause: It maybe that use the same hosting plan for all your websites.
As free app service plan doesn’t support custom SSL, if you want to use your user custom SSL then need to scale up to app service plan from to basic or higher.
After scaling up the App service plan, it will apply to all your websites in your app service plan.
2. How to resolve it
Please have a try to create another free app service plan for the 3 websites. Detail please refer to how to create-a-new-app-service-plan and Move an app to a different App Service plan.
Note: Only valid plans (in the same resource group and geographical location) are shown.
With Azure websites you are basically renting an IIS instance. In order to use SSL on your website you need to switch your plan to "Basic" or higher, as you've seen. Right now I think all of your websites are in the same "webhosting" plan. This means that they are automatically scaled to the "Basic", as you are basically scaling the IIS instance, not the indiviudual website.
See it as buying a hosting plan that can host multiple web applications. If you move to basic, you end up paying for 1 basic plan that hosts all 4 sites (so not 4 billable plans, just 1).
In this case you won't end up with a higher bill (you need a basic instance for the SSL-site anyway) - the other sites are including in this same hosting plan for 'free' - sharing the resources of the basic instance).
If you want to keep the basic site and the 3 free sites separated, you should create a new webhosting plan (App service plan) on the new Azure Portal (https://portal.azure.com) and move those 3 websites there.
I would recommend letting those 3 sites use the basic plan - it won't cost you any extra.
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 have a single .NET website that is currently running under a traditional hosting account.
I am using a multi-domain (5 domain) SSL certificate to handle domains for different regions i.e.
https://www.mywebsite.com
https://www.mywebsite.net
https://www.mywebsite.de
https://www.mywebsite.at
https://www.mywebsite.co.uk
At a code level I detect the address and localize the site depending on the URL extension.
This has all worked perfectly for the past few years with no problem. Now I want to migrate this site to Windows Azure to allow for better performance and redundancy.
I have successful experience of setting up a site using a Wildcard SSL certficate under Azure (i.e. *.mywebsite.com) but I am keen to sound out whether the multi-domain SSL is also possible.
So my question is does Azure support this kind of certificate and setup, has anyone successfully achieved this and were there any pitfalls?
Just to follow up on my question, it was very simple to implement in the end. I uploaded multiple certificates against my cloud service and the code then worked as before.