Azure Traffic Manager causing HTTPS site to show “Not Secure” even though SSL certificate is valid on NGINX

Question

Azure Traffic Manager causing HTTPS site to show “Not Secure” even though SSL certificate is valid on NGINX

Durgesh Mishra 60

Hi Microsoft Community,

I have the following setup:

Client Browser
     |
     | HTTPS
     v
www.example.com
     |
     v
Azure Traffic Manager
     |
     v
NGINX Server
     |
     v
Web Application

The NGINX server has a valid wildcard SSL certificate (*.example.com), and the application works correctly over HTTPS.

However, I am seeing the following behavior:

When I bypass Azure Traffic Manager and point www.example.com directly to the NGINX server, the website loads correctly and shows as Secure.

When I access the website through Azure Traffic Manager, the website loads, but Microsoft Edge shows “Not secure”.

When I click the site information icon in Edge, it shows “Certificate is valid”, but the browser still displays the overall connection as Not secure.

The same NGINX configuration, SSL certificate, and application work correctly when Traffic Manager is bypassed.

My understanding is that Azure Traffic Manager is DNS-based and does not terminate SSL/TLS, so the browser should ultimately establish the HTTPS connection directly with the selected NGINX endpoint.

I would like to understand:

Why could Edge show “Not secure” when the certificate itself is reported as valid?

Are there any Azure Traffic Manager endpoint or DNS configurations that could cause this behavior?

Are there any specific HTTPS/SNI considerations when using a wildcard certificate with Traffic Manager?

What would be the recommended troubleshooting steps to identify whether the issue is related to Traffic Manager, DNS resolution, or the backend NGINX endpoint?

Any guidance would be appreciated.

0 comments

1 answer

Your answer

Answer 1

Hello @Durgesh Mishra

Your understanding is correct. Azure Traffic Manager does not terminate or proxy HTTPS traffic. It only answers the DNS query with the selected endpoint; the browser then connects directly to that endpoint and performs the TLS handshake there.

Because Edge reports that the certificate itself is valid, look beyond the certificate first. A page can still show as Not secure if, for example, the HTML loads over HTTPS but some page resources load over plain HTTP (mixed content).

One useful test is to open Edge Developer Tools → Console and Network, reload the page through Traffic Manager, and look for mixed-content warnings, HTTP resources, redirects, or requests going to a different hostname.

Also, compare DNS and TLS results between the working and failing paths:

nslookup www.example.com
curl -Iv https://www.example.com/
openssl s_client -connect <resolved-IP>:443 \
  -servername www.example.com

The -servername option is particularly important because it tests SNI using www.example.com. Your *.example.com certificate should cover www.example.com, but each NGINX endpoint returned by Traffic Manager must be configured to serve that certificate for the www.example.com SNI hostname.

Also check whether Traffic Manager has multiple endpoints. If only one NGINX endpoint has the correct certificate/configuration, DNS-based routing could explain why bypassing Traffic Manager works while normal access behaves differently.

Traffic Manager's HTTPS health probe won't catch a certificate/SNI problem because Microsoft states that HTTPS monitoring does not validate the TLS certificate; it only checks that a certificate is present.

So, compare each Traffic Manager endpoint individually using the same Host/SNI name, and also check the Edge Console. If you can share the exact Edge security warning or Console message (with the actual domain/IP removed if necessary), that should narrow this down considerably.

References:

How Azure Traffic Manager works

Azure Traffic Manager endpoint monitoring

Secure an Azure Traffic Manager deployment

Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.