In our scenario, we are providing SaaS platform which will automatically create customer specific traffic manager (xxxx.trafficmanager.net) each time when customer onboard our platform.
The traffic manager will points to app service cross regions.
The problem is, that if customer calls the traffic manager with HTTPS, the CERT warning will be shown. I know we can bind the cert to each of customer's traffic manager and upload the cert to azure. But since the traffic manager is automatically created in runtime, how can we automatically get a cert and bind to xxx.trafficmanager.net?
Traffic Manager works at the DNS level. It sends DNS responses to direct clients to the appropriate service endpoint. Clients then connect to the service endpoint directly, not through Traffic Manager. You will bind your cert to the endpoint, not Traffic Manger. If the endpoint is an Azure Web App, you can use the CLI or Powershell to bind the cert.
Therefore, Traffic Manager does not provide an endpoint or IP address for clients to connect to.
Traffic Manager supports probing over HTTPS. Configure HTTPS as the protocol in the monitoring configuration.
Traffic manager cannot provide any certificate validation, including:
Server-side certificates are not validated
SNI server-side certificates are not supported
Client certificates are not supported
Related
I have a pretty simple setup with an Application Gateway (AG), that sends traffic to a virtual machine running Ubuntu. The AG is loaded with an SSL certificate. The VM is set up to only allow incoming traffic from the AG, but it's an HTTP connection. This works, but I want to secure the traffic between my VM and AG. I can't find any relevant settings or documentation for this however.
How do I encrypt traffic between an Application Gateway and Virtual Machine? I considered a private link to at least force traffic over the Azure network, but private links only support PaaS products, where a VM is IaaS.
I assume your use the private IP of your VM in the backend settings of your Application Gateway. If so, this means that the traffic stays within your VNET and thus on the Microsoft network and also within the same region. You do not not need something like Private Link here.
So the only thing you could potentially do is to SSL-enable the endpoint on the VM and use an encrypted HTTPS connection between AppGW and your VM.
you have to do the same thing as with the api-gateway, load a certificate into de service deployed in the virtual machine and expose the API of this service using SSL protocol so the communication will be encrypted using that certificate.
The way to do it is different depending on which technology you are using to deploy your service. For example, if you are using spring-boot you can see how to do it here
https://www.baeldung.com/spring-boot-https-self-signed-certificate
However, you can use mutual-tls if you want that the only service that could connect to your VM's deployed service is the AG.
https://developers.cloudflare.com/access/service-auth/mtls
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 an Azure App Service with HTTPs enabled only and Azure Active Directory as a way to Authenticate to the service.
I am planing to geo-locate my App Service on a second region but at the moment I am trying to test that Azure Traffic Manager works with my current site. However, there are few things that are confusing me:
When I created the ATM, the DNS name was HTTP and not HTTPs. Seems there is no option to have a DNS name with HTTP.
After I added the endpoint, I tried to navigate to the URL http://foo.trafficmanager.net and it redirects to https://foo.trafficmanager.net/ and shows the following error. This site is not secure. Seems there is a certificate error. Why is rerouting automatically to HTTPs now?
Is there any documentation step by step to configure ATM? I am not interested in purchasing a domain, I am totally fine with https://foo.trafficmanager.net/ as my URL as long as the connection is secure all the time.
Azure Traffic Manager supports probing both over HTTPS and HTTP. For HTTPS:
Server-side certificates are not validated
SNI server-side certificates are not supported
Client certificates are not supported
There are more details you can take a look: FAQs and Traffic Manager endpoint monitoring.
With HTTPS, the monitoring port should change from 80 to 443 and also your monitoring path points to a valid page for your service.
Update
There is an issue that what does Azure Traffic Manager work. For more details, see What is Traffic Manager.
Azure Traffic Manager is a DNS-based traffic load balancer that
enables you to distribute traffic optimally to services across global
Azure regions while providing high availability and responsiveness.
The DNS of Traffic Manager itself just uses the HTTP protocol. But it can probe both HTTP and HTTPS. All the HTTPS for your application just set in your Web App Service.
Hope this will help you.
I have a Website running on Azure. I added a custom domain and an SSL to enable https access to it.
All is fine. Few days ago Azure had a network issue in a datacenter where my website is hosted( West Europe) and of course my site was affected during that time.
So i've decided now to put my site under traffic manager and deploy it in 2 regions.
Configuring Http acces with ATM works. But when i switch to Https( choosing https protocol in ATM config page) all endpoints get "Degraded" status.
so, my questions are: do i have to add certifcate to traffic manager in order to use https? How can i add https endpoints to ATM?
Traffic Manager supports health probes via both HTTP and HTTPS. Note that when using HTTPS health checks:
The server certificate is not validated (hence there's no need to
register the certificate with Traffic Manager)
Client certificates are not supported
SNI certificates are not supported
Please check the above. Please also check that your 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.
These pages may be helpful:
Traffic Manager endpoint monitoring
Troubleshooting 'Degraded' endpoint status
If you still can't get it to work, please raise a Support ticket. If you do solve the problem, please reply back to let us know what it was
Regards,
Jonathan Tuliani, Program Manager, Azure Traffic Manager
I have an F5 load-balanced 4-server cluster environment that I'm building, so I'm looking to centralize our certificates to prevent needing to install them all on every server. Windows 2012 / IIS 8 seems to have centralized certificates, but that is only to secure my endpoint in IIS for inbound traffic.
What about for outbound traffic? They all will be initiating TLS transactions to external entities, so I need a way to store all these on a single server and have each of the IIS boxes "tap into" that cert store for the private and public keys that are necessary to send that TLS message.
Any suggestions?
You're looking for an HSM which the F5 will support and IIS also supports a few major vendors (Thales and Safe-Net both have IIS supported HSMs). They're not cheap from what I remember but that's exactly what you're looking for.
If you don't want to go that route, you can opt for the dirty solution of using the BIG-IP as your cert store and rely on self-signed certs on the IIS pool members.
Inbound: Incoming traffic terminates on BIG-IP using the valid CA-signed cert SSL Client profile. BIG-IP re-encrypts to IIS using a generic SSL server profile. Not pretty but it works.
Outbound: You would have to use the BIG-IP as the default gateway of the IIS server so you can direct the outbound TLS from BIG-IP instead of IIS directly.
Devcentral: SSL Acceleration - Can I encrypt outbound traffic
Hope this helps.
-Chase