TL;DR;
What's the way to distribute an SSL certificate across regions, so that no matter which region the application is hosted - it will serve the SSL certificate for the requested custom domains.
Explanation:
We have an Azure Web app where we add custom domains per user. We want to scale the app in different geographic regions behind a traffic manager so that when the website is accessed from Australia - it will be served from the Auatralia's Web App, and when the request comes from Europe - the web app in Europe will serve the request. So, in current situation, regardless of where the request is coming from it will always be served from one location, for example: Europe.
The challenge here is we can add the custom domain in only one of the web app, due to the fact that you need a CNAME entry pointing to an individual URL. It cannot point at two different URLs at the same time. It is possible to route the requests to individual apps but the other web app will not be able to serve the SSL certificate if it's mapped on App1 in region1.
How to distribute or maintain the pool of certificates which can be access by the web apps in different regions? Is there any way with Microsoft Azure?
Update:
We are going to have N number of custom domains, and so N number of SSL certs to handle. AFAIK, Azure Front Door and Azure Traffic Manager - we can map a custom domain to their own endpoints, and is limited to one custom domain. Here I'm talking about handling thousands of external custom domains/SSL Certs.
Thanks in Advance! 🙏
Instead of using Traffic Manager, I would use Azure Front Door. This has a built-in SSL certificate management. You don't even need to purchase the certificate yourself.
What I understood from the question is basically you would like to address the request from the same region rather than from one location. In that case, I would suggest have a look at azure application gateway. Here, you can define path-based load-balancing rules. In that path based, basically you can have one attribute which identifies location say /api/emea/images, /api/apac/images. Off-course you need to first define API on these lines to accommodate some kind of identifier. Once done, then based on this you can create this load-balancing rule in application gateway. Then, you can have different backend pools say one sitting in EMEA region with four-five virtual machines, that can handle traffic from EMEA region. Similarly, it goes for another region as well. Try implementing the same on these lines. You can also explore front door option as well as it handles load-balancing globally and your certificate related stuff should also get addressed. It should address your problem.
We purchased a domain name from Network Solutions, and set up our website as two App Services in Azure (one within US East and one within US West). Our domain name purchased from Network Solutions is assigned as a hostname in Azure, and a traffic manager balances the traffic between the two App Services. I have two questions...
Azure offers SSL Certficates. If I purchase an SSL Certificate from Azure, is there anything I need to do in Network Solutions to update the site?
Do I need to purchase two SSL Certificates since I am using two App Services?
I have looked at these articles, but unfortunately, they did not answer my questions:
https://learn.microsoft.com/en-us/azure/app-service-web/web-sites-configure-ssl-certificate
https://learn.microsoft.com/en-us/azure/app-service-web/web-sites-purchase-ssl-web-site
Thank you!
If you already have a custom domain associated with your Web Apps (both deployments Region #1 and #2), then no. You're all set.
E.g. www.example.com pointing to {TrafficManagerName}.trafficmanager.net
No. Just one TLS certificate valid for www.example.com or *.example.com
See my answer here for more:
https://stackoverflow.com/a/40399500/4148708
In the next several months we will be going live with a web app ('MyApp') that is being hosted on Azure. We have purchased the MyApp.com domain and our Azure domain name is MyApp.azurewebsites.net.
We do not want our users to ever see the azure domain name in any form. We want them to see www.MyApp.com or www.MyApp.com/Sales/ViewSale etc.
I think I know how to map www.MyApp.com to MyApp.azurewebsites.net based on this article. We won't be able to set this up for a while, so I'd like to know what the user will see in their browser URL when they go to www.MyApp.com. Will they see www.MyApp.com or MyApp.azurewebsites.net? And then what will they see as they navigate various pages in the app?
Your azure website needs to be at least at the 'shared' level. This is the first tier of 'paid' azure website hosting. You do this under website > scale.
app service plan pricing tier = shared.
then you would choose 'configure' and look for 'domains' and add your www.myapp.com domain.
Then you head out to your DNS manager and add a CNAME record that directs traffic from www.myapp.com to myapp.azurewebsites.com, OR you can lookup up the Virtual (public) IP of your azure website and update the A record in your DNS manager.
Either route, your visitors will see www.myapp.com/mypage, www.myapp.com/mypage2, etc.
Once you have the proper hosting level (the control panel will tell you, look for custom domains) and configuration, they can access it as www.myapp.com. You may need to provide your own SSL cert in order to configure it as well.
When it comes time to SSL, check out this post (Azure SSL Certificate) that I made regarding uploading of SSL certs in the control panel. It will save you a headache.
The article you linked appears to have solid information based upon my recent experiences. One thing to note: It has screen shots from the old configuration panel, so some things may look different in the new one.
I haven't found a way to hide the myapp.azurewebsites.com method to access a page, other than maybe doing a redirect inside your code. However, until you have your DNS setup it might be nice to see things working under that domain to start.
Background:
I'm hosting 2 separate Website instances - 1 for a WebAPI2 "API", and 1 as an MVC5 "Client" that consumes said API. I would like to restrict access for the "API" to the "Client" (there are multiple clients)
(I've only seen answers for Cloud Services or VMs, so wanted to ask if there was anything I could use for Websites. I don't want to use a cloud service or a VM, as the website is faster, lighter, cheaper - which is what I need.... could not find a firewall feature for Websites in Azure.)
Problem:
I believe I can limit access to the "API" by setting parameters in the project's Web.Config file.
But nslookup in the command prompt yields the same IP Address for all azure websites under my account.
Question:
How do I find the right IP Address -- one that the "Client" website will use to access the "API" Website instance?
If there is a better way to restrict access...please do suggest it.
You cannot secure your site by IP ACLing as web sites in Azure are running in a multi-tenant environment and they share set of IP addresses (IP addresses are per DC).
You need to rely on different security mechanisms (using some secret which only client/server know etc.).
Hope that helps.
You can also take a look at How to determine Azure website outgoing IP Address?
Petr
I've been trying to find an answer to this for a few days.
I want to host a new azure website in either the Basic tier or Standard tier.
The site will be calling a third party service.
I need to give this service provider an IP address that they will whitelist.
So when the new azure website makes requests to this service the IP address for the request needs to always be the same, as this will be the IP whitelisted.
I read that Azure offers "Reserved IPs" for cloud services and VMs but I wanted to know if something similar can be done with Azure Websites as I really don't want to go with cloud/VM.
My knowledge of networking is limited but as I understand it, if I were to get an IP SSL cert and apply that to my Azure Website then the website would have a static IP address.
If that is the case, would any requests to the third party service be hitting the service providers external firewall with this same static IP?
Thanks for any advice people can give.
An SSL cert with Web Sites will be tied to an inbound IP address. However, Web Sites does not provide a static outbound IP address.
If you need a static IP address to align with 3rd-party services, you'd need to have something residing in Azure (e.g. Application tier) running in a cloud service / VM that your web site accesses, and then have that app tier (with static IP address) communicate with your 3rd-party services.
As David Makogon's answer points out, applying an IP-based SSL certificate only gives the website a static inbound IP address.
However, the outbound IP address a website uses when making outbound network calls can be determined based on where your website is hosted. Microsoft has a list of the these IP addresses here. The third-party service would have to whitelist all of the IP addresses used by the scale unit your website is hosted in (e.g. waws-prod-am2-005).
Correct me if I am wrong, but the information shared by Brant Bobby above shows that, in fact:
All Azure websites (/Web Apps) already have a discoverable and published outgoing IP address.
This outgoing IP address will never be unique to their own site however. So one must keep in mind if they use it for a white-list, it will be allowing in a lot of other Azure visitors hosted on the same scale unit.
Simply get the so-called "scale unit" name for your site, which is the same as what's given in your site's FTP address (and so forth), which is in the format: "waws-prod-[3LetterVar]-[3DigitNum]", e.g. waws-prod-blu-007.
As an example from that article, all the East US region Azure websites can find the four IP addresses their site may rely on as follows (so if white-listing, all 4 should be white-listed):
East US Region
Outbound IP addresses for each scale unit, currently 4 for each. They said they may add more IPs to each scale unit in the future, but these should not change.
waws-prod-blu-001: 168.62.48.13, 168.62.48.19, 168.62.48.33, 168.62.48.122
waws-prod-blu-003: 137.117.81.128, 137.117.81.142, 137.117.81.181, 137.117.81.82
waws-prod-blu-005: 137.117.80.189, 137.117.81.52, 137.117.81.90, 137.117.80.178
waws-prod-blu-007: 23.96.33.205, 23.96.34.196, 23.96.35.20, 23.96.36.229
waws-prod-blu-009: 23.96.97.203, 23.96.97.233, 23.96.97.235, 23.96.97.238
waws-prod-blu-011: 23.96.112.60, 23.96.112.117, 23.96.112.152, 23.96.112.15
waws-prod-blu-013: 191.238.8.154, 191.238.9.80, 191.238.9.94, 191.238.9.170
waws-prod-blu-015: 191.236.19.222, 191.236.19.242, 191.236.21.165, 191.236.18.160
waws-prod-blu-017: 191.238.32.104, 191.238.32.154, 191.238.34.67, 191.238.35.12
waws-prod-blu-019: 104.45.138.197, 104.45.142.87, 104.45.128.144, 104.45.142.131
waws-prod-blu-021: 191.237.24.189, 191.237.30.36, 191.237.26.164, 191.237.28.161
waws-prod-blu-023: 191.236.50.206, 191.237.30.215, 191.237.25.148, 191.237.22.195
waws-prod-blu-025: 191.237.31.86, 191.237.26.176, 191.237.20.70, 191.237.18.239
Azure now supports having static outbound IP address as well.
https://azure.microsoft.com/en-us/documentation/articles/app-service-app-service-environment-intro/
If we do not want to go for costlier App Service Environment setup, we can directly use the outbound IP addresses mentioned in the Azure portal in properties section, Azure assures that it remain 99.9% static. Nothing really changes until there is some changes data center wide. Moreover, the reserved Ip what we use in IaaS is also not 100% reserved for us and azure provides SLA of 99.9% here as well. So, In my opinion, instead of going for ASE and hosting IaaS and using reserved IP, we can just use outbound Ip provided by azure, since we get same reliability in both cases.