HTTPS/SSL Certificates and traffic on Azure - From CDN (custom domain with SSL) to Traffic Manager and end to end flow

1
votes

We have been working on a flow of upstream services on Azure. The following is the architecture:

User -> DNS -> Azure CDN -> Azure Traffic Manager -> Frontend Load Balancer (Firewall NVA) -> Azure Application Gateway -> Backend Pool (VM-Webserver)

The above flow was designed for a client and we are provisioning the same. The entire end to end flow works with HTTP requests.

But for HTTPS with SSL, the flow works only till traffic manager, as soon as we add CDN in the flow, it gives error, 'Request cannot be served', when checked in browser, it shows 502 bad gateway in developer tools

What we have seen so far:

  1. The end to end flow is working seamless for HTTP requests For
  2. HTTPs/SSL requests following configs have been done:
    a) CDN : We have a profile with Custom Domain and HTTPS and Certificate enabled over it.The profile has both 80,443 enabled
    b) Traffic manager : Endpoint set to port 443
    c) Application Gateway : Plan to use end to end SSL encryption
    i) Listener is on 443 port and has a pfx certificate
    ii) HTTP setting with HTTPS and has a cer certificate from the original webserver

We have tried different combinations of configuration with CDN and traffic manager but doesn't seem to be working. I need this flow to be working end to end for HTTPS requests. This is for a prod migration to Azure.

1
azuresslazure-cdnazure-traffic-manager
Enable diagnostics in App Gateway, check that your requests are even arriving. Make sure probes for your https settings are all healthy in App Gateway. – milope
Also wanted to add, when configuring end to end SSL, it’s best to test one from from the origin, make sure it works, then two hops, make sure it works, etc. End to end SSL in App Gateway will require App Gateway to trust (v2) or whiteliste (v1) the SSL certificate presented by the backend. If you are using SNI, you may want to use an FQDN as your backend address pool as, at least in v1, using an IP will not send an SNI extension during the SSL handshake, I believe. – milope
Here is an official doc to set up failover across multiple Azure CDN endpoints with Azure Traffic Manager for your reference. – Nancy Xiong
Your architectural design seems to be wrong. You cannot place Traffic manager behind Azure CDN. Traffic manager is a L7 DNS based load balancer. Traffic manager need to be in front of Azure CDN – msrini-MSIT

1 Answers

1
votes

Sorry for not following up and reverting on this. As for the above issue and requirements, it was resolved. Following were the steps taken:

  1. CDN was configured with Origin type was select as Custom Origin - Original Hostname was given as traffic manager URL For Eg. abc.trafficmanager.net. Origin Host Header was left as blank
  2. For Traffic manager profile changed the endpoint as Azure endpoint selected Target resource type as Public IP Address and added the public IP address of Load Balancer
  3. For Application Gateway, it had to be made sure that we used PROPER CA CERTIFIED CERTIFICATE for end to end SSL encryption, we were trying it with self signed one hence did not work. We purchased one and used it, CDN responded as expected
  4. Another important observation was that, for Application gateway in the HTTP settings (i.e. backend settings), the same CER certificate can be used for multiple websites for backend server certificate whitelisting. The certificate (cer) that you wish to use, set it as the default certificate on your server, say for a particular website named abcxyz.com. Then the certificate of abcxyz.com can be used for whitelisting the backend for all the websites on that server

In short, app gateway backend only checks if the certificate (cer) is valid, it has nothing to do with the hostname or the certificate is of which domain, if the certificate matches and is valid, it is whitelisted

So folks, with all the detailed study and trails with logical reasoning, we were able to get the same exact flow as mentioned above working for both HTTP and HTTPs, with SSL encryption as well as SSL offloading for application gateway.

Thank you once again for all the support and suggestions !!