I have an Azure App Service that will have a custom domain and SSL binding in Production. Normally, I would issue the certificate first for the domain, bind to the App Service using an IP-based binding for the given domain, then update DNS entries as required once I know the IP address that Azure has bound.
My client will be issuing the certificate, and they won't do this until they know the exact inbound IP address that will be used for the SSL binding, but I don't believe I can know this IP until I've actually created the binding (which requires the certificate!) so it's a nasty chicken-and-egg scenario.
Is there a way of reserving a static inbound IP address in Azure for this purpose, prior to requiring the certificate? Or would I need to use some sort of gateway in front of the App Service instead, or some other solution I haven't thought of?
Not sure why your client doesn't want to issue the certificate until knowing the exact inbound IP address unless they are trying to have an SSL certificate for the IP address not for the domain name.
If not, to get a reserved or dedicated inbound IP address for the web app, you can easily install and configure an IP-based TLS/SSL certificate at a low cost. Then if the IP address is updated, you just need to update the A record with the new IP address in the DNS provider.
For other choices, you can use either an isolated and dedicated environment for your app service plan or set app service behind an application gateway V2 SKU. See how to Configure App Service with Application Gateway. You can also enable end-to-end TLS by using Application Gateway. Whatever you select one of them, has a higher cost and complicated configuration.
Related
So I'm working on building scripts to deploy Azure resources using the Az modules in PowerShell. I am new to Azure Traffic Manager, so I'm wondering if what we are looking to do is even possible, and if so, how.
We have an API Management Service (APIMS) with a handful of APIs in it that point to a few different web apps within Azure. So the way it works currently is we have a client application that will post to a specific API operation via its APIMS URL.
We are looking at the idea of using Traffic Manager purely for moving traffic from one APIMS to a another in the event that we need to create a new APIMS. I can add the existing APIMS as an endpoint to the Traffic Manager as an external endpoint using its public IP address. But beyond that, here's what I'm unsure of:
How exactly would traffic actually get routed through the traffic manager, through the APIMS, to the specific API post? (as in, what would the client application need to specify as where it's sending its post?). Or would this even work??
If we create a new APIMS, can we then simply add that as a new endpoint to the traffic manager (again, as an external endpoint via its IP address), and then delete the old APIMS endpoint?
I did find this question that's similar, but that answer is using Add-AzureTrafficManagerEndpoint as opposed to New-AzTrafficManagerEndpoint, which is what I'm using and apparently does not support -DomainName as a parameter.
Traffic manager does not route traffic, it only does domain name resolution. You could use TM for that. For your custom domain in traffic manager (say contoso.com) you can add CNAME record pointing to contoso.azure-api.net (it's preferable to use CNAME instead of A and APIM service IP may change in certain scenarios). And add SSL certificate in APIM for contoso.com. What will happen in that setup:
Client wants to make request to https://contoso.com/myapi
Client will perform DNS lookup for contoso.com and see CNAME record pointing to contoso.azure-api.net
Client will perform DNS lookup for contoso.azure-api.net and see APIM IP address
Client will try to open SSL connection to APIM
APIM having SSL certificate available will accept the connection
Client will send request.
All this does not require any special configuration from your client apart from setting it up to use "contoso.com" as a hostname for your API. Later if you want to switch to a different APIM service you could go and update TM. Client will not require any changes.
The one thing to know is that this particular setup does not require TM per se. As all you really need is a custom domain from any DNS provider because all you need to do to switch traffic from one APIM to another is update CNAME record.
I have created Windows Server VM in Azure and deployed my site to IIS, which is now accessible at https://mysite.westeurope.cloudapp.azure.com/
however I get certificate error when I try to visit it from outside the vm.
how do I configure the VM to have proper https without certificate errors (just like app service - mysite.azurewebsites.net)?
As the comments from micker #micker, you can't get an SSL certificate for this subdomain westeurope.cloudapp.azure.com which is owned by Microsoft.
Since you host your websites on Azure VM, you could purchase a domain then get an SSL certificate for your own domain, then bind the SSL certificate to your custom domain in IIS on the Azure VM. You can either purchase that certificate through Azure or an external provider or get a free SSL cert from Let's Encrypt.
However, if you just want to have a test in your test environment, you can use a self-signed certification with this DNS name like vma.centralus.cloudapp.azure.com. You can follow steps in How To Create A SHA-256 Self-Signed Certificate on the Azure VM then export this cert .cer format file on the Azure VM and import the .cer cert under the mmc---certificate---local machine---Trusted root certification Authorities on the machine where you want to access the websites. Please note this It's not recommended to use self-signed cert in your production environment.
I had same issue, and I found resolution without custom domain using following additional azure settings.
create Azure WAF, add custom rules to deny if not in IP list - this is if you need ip whitelisting, useful if your main domain uses akamai or other edge routing to point to external hosting of subdomains, you can use whitelist to restrict access to the akamai or other servers, though this takes some big lists you must paste of ranges one row at a time. Set any other web app firewall rules you want enforced for allow/deny.
Create Azure Front Door named like you want as an endpoint url e.g. myappfrontdoor will make myappfrontdoor.azurefd.net. in backend pool specify the your public-ip shared dns name (see step 3) like myapptest..cloudapp.azure.com.
This is the important step : in Settings at top of front door designer, disable cert validation. in routing rules config, no condition, forward to backend pool setup in prior step. This ignores the fact that you cannot cert your cloudapp.azure.com endpoint, and wraps it with a *.azurefd.net certificate.
In your azure firewall, Edit NAT rules, set rule name myapp-web-fd-... , tcp, ip address, 147.243.0.0/16 (this is Azure's front door backend ip range). destination should be the firewall's own public ip. destination port 443, translated address should be the target vm's azure internal ip, target port - service port.
Now you will have a site like myappfrontdoor.azurefd.net.
Note that Azure Front Door and WAF have their own pricing costs, so maybe it is cheaper for you to buy a domain. Hopefully you are also using Azure Firewall, though expensive. If not, one could point to public ip directly on NSG or on vm itself but I wouldn't skip having a firewall for a public server. There is a standing Azure enhancement request to get Azure Front Door to recognize certificates, but it was triaged 2 years ago and still not added, so not sure if it will be worked. If it ever does get worked, devs could make own cert auth and self-signed cert with expirations to more securely hook front door to azure internal vm. For now, have to rely on the front door backend setting, waf, and azure firewall to have these things routed.
There are some options in Akamai and other edge routing systems to import cert and self-created authority sort of, but I've not tried that yet, so cannot confirm this would cleanly wrap your azure site without cert errors. You can make a self-signed authority using openssl commands as noted in other posts out and about on the web.
The simplest and cheapest option is to purchase a domain and use a cname dns record to map your new domain to your Azure subdomain address - an "A" record is not required. Also per answer above, a WAF is expensive and possibly unnecessary for a test set up (but a requirement for a production website). You can use Certbot and NGINX to create a free Lets Encrypt certificate for your domain and assign it to your website.
Adding a Public IP Address, Load Balancer, and Network Security Group to your Azure Resource Group may also be required to provide access to your website. This is largely how my test configuration is set up except I'm using a Linux VM, have a single wildcard certificate, and use NGINX to reverse proxy 3 websites.
Say, I have two app service (HTTPS only is enabled):
https://myapp1.azurewebsites.net
https://myapp2.azurewebsites.net
I can call both app service endpoints using HTTPS successfully.
Then I created a traffic manager and add above two endpoints to traffic manager, say:
myapps.trafficmanager.net
After the traffic manager is created and endpoint added, the trafficmanger host name myapps.trafficmanager.net is also automatically added into custom domains of two app services. But without SSL binding to traffic manager host name.
Then if I call traffic manager endpoint using HTTPS: https://myapps.trafficmanager.net, I will got untrusted SSL cert error/warning. That is expected.
Since traffic manager just works on DNS level, the real request is actually send to the app service endpoint which has correct SSL cert binding. My question is:
From security point of view, is it safe to call the non-cert binding traffic manager endpopint using HTTPS in my code (say, using .NET HttpClient) but just ignore the cert error?
I recently set one of these up as well and fought with it for a bit. The short answer is that it is probably safe, but it sounds like you may be using the Traffic Manager incorrectly. You shouldn't be using the URL in the Traffic Manager as your end point if you want to use SSL. Instead configure your vanity domain name, mycoolsite.com to point to myapps.trafficmanager.net, using a DNS CNAME record.
If you want to use SSL and a single URL you should configure the custom URL and install an SSL cert at the service level. It should be same custom URL on both app services. This must be configured at in the app service, not in Traffic Manager.
I had to read this a few times to understand how it works under the hood, but it was helpful.
So in summary, to set it up properly, the steps would be:
Configure custom/vanity domain on both app services
Install the SSL cert on both app services
Setup and configure the Traffic Manager
Point the custom/vanity URL to the traffic manager using a DNS CNAME record
There is no need to bind a cert with traffic manager since the server certificate is not validated when using traffic manager health probes via HTTPS. Moreover, the traffic manager works at the DNS level. The clients connect directly to the selected endpoint, not through Traffic Manager.
In this case, you could use HTTPS for endpoints and use health probe via HTTPS. Even you could not bind a cert with traffic manager, you could make sure that the monitoring port is configured correctly in Traffic Manager (e.g. 443 instead of 80) and also your monitoring path points to a valid page for your service.
Another SO answer explains this more details. If you still want to make this warning disappearing, you can get a free SSL from letsencrypt.org and add that to your custom domain with the *.trafficmanager.net.
I have created an App Service Environment and have multiple web app and web API associated with it. I want to achieve an arrangement where only my App service has access to the API, so trying to block traffic to the API using IP Restriction. But all the Web Apps as well as the web API has the same VIP and i cant find any other IP address associated with it.
Also to attach the NSG to the subnet(in which ASE is there), we need to add rules which again need specific IP. How can I achieve this?
I assume you have provisioned external ASE.
"App Service has the ability to allocate a dedicated IP address to an app. This capability is available after you configure an IP-based SSL"
So, you can limit the access to some of your apps inside the ASE by using App-assigned IP-based SSL addresses (Only possible with an External ASE and when IP-based SSL is configured).
When you provision your ASE, you can select how many external IP addresses the system should have including those for IP-based SSL purposes.
please see: https://learn.microsoft.com/en-us/azure/app-service/environment/using-an-ase#ip-addresses and slide nr.14 here https://8gportalvhdsf9v440s15hrt.blob.core.windows.net/ignite2017/session-presentations/BRK3204.PPTX
My azure app service shows secure sometimes and sometimes it shows as not secure to browse. I have uploaded CA issued SSL certificate to acquire a dedicated inbound IP. Not sure but seems when load increases the app service shows as unsafe to browse. Also there are performance issues and responds slowly.please suggest on how to show it as secure always and have better performance.
My best guess is that you have a load balancer configured within Azure and the second node that is receiving connections is not assigned your ssl certificate. I'm guessing the reason you are only seeing the issue under heavy load is because your load balance is using a weighted connection algorithm to route new connections to either a newly created or already provisioned node when the first node has reached a high enough active connection count.
If this is your issue, and you discover that you have an internal load balancer (ILB), here is Microsoft's guide to Using an Internal Load Balancer with an App Service Environment.
Go to ASE UI after ASE is created ASE -> Settings -> ILB
Certificates
Set ILB certificate by selecting certificate pfx file and provide
password. This step takes a little while to process and the message
that a scaling operation is in progress will be shown.
Get the ILB address for your ASE (ASE -> Properties -> Virtual IP
Address)
Create a web app in ASE after creation
Create a VM if you don't have one in that VNET (Not in the same
subnet as the ASE or things break)
Set DNS for your subdomain. You can use a wildcard with your
subdomain in your DNS or if you want to do some simple tests, edit
the hosts file on your VM to set web app name to VIP IP address. If
your ASE had the subdomain name .ilbase.com and you made the web app
mytestapp so that it would be addressed at mytestapp.ilbase.com then
set that in your hosts file. (On Windows the hosts file is at
C:\Windows\System32\drivers\etc\ )
Use a browser on that VM and go to http://mytestapp.ilbase.com (or
whatever your web app name is with your subdomain)
Use a browser on that VM and go to https://mytestapp.ilbase.com You
will have to accept the lack of security if using a self-signed
certificate.