Facing Issues with Mutual TLS Configuration for Specific Routes in Azure Application Gateway

Ganesh Chowdhary 0

We need to support two APIs accessible through the domain device-api-server.com using Azure Application Gateway:

Bootstrap API

Path: /api/bootStrap Request Method: POST Authentication: No authentication required.

Handshake API

Path: /api/v2/handshake Request Method: POST Authentication: Requires mutual TLS (SSL validation). Current Setup:

We created two listeners in the API Gateway configuration:

Bootstrap-Listener: Listens on device-api-server.com. No certificate validation is required. Path Forwarding Rules: Requests to /api/bootStrap are forwarded to the backend pool onboarding-service. Requests to /api/v2/handshake are routed to the Handshake Listener.

BootStrap-Listener

bootStrap Rule

bootstrap_rule

handshake listener

image (9)

handshake rule

handshake_rule

Issue: When a request is sent to the Handshake API via the Handshake Listener, the response is:



  
    
    
  
  
    <h2>Length Required</h2>
    <hr>
    <p>HTTP Error 411. The request must be chunked or have a content length.</p>

It looks like Content-length header is getting dropped when Path Rule "/api/v2/handshake" is forwarding the request to Handshake-Listener"

Requirement:

How can we configure Azure Application Gateway to ensure:

The Bootstrap API remains accessible without authentication?

The Handshake API performs mutual TLS validation while avoiding the HTTP 411 "Length Required" error

Ganesh Patapati 2,825 Reputation points Microsoft Vendor

2024-12-31T12:58:29.58+00:00
Hi Ganesh Chowdhary

Greetings!

Welcome to the Microsoft Q&A Platform. Thank you for reaching out & I hope you are doing well.
To resolve the issues with your Azure Application Gateway configuration, ensure that the Bootstrap API remains accessible without authentication and that the Handshake API performs mutual TLS validation while avoiding the HTTP 411 "Length Required" error.

Azure Application Gateway HTTP settings configuration

TLS policy overview for Azure Application Gateway

Bootstrap API Configuration

For the Bootstrap API, you have already set up a listener that does not require certificate validation. This setup should work as intended since no authentication is needed.

Handshake API Configuration

For the Handshake API, the issue appears to be related to the Content-Length header being dropped when the request is forwarded to the Handshake Listener. Follow these steps to configure Azure Application Gateway to avoid the HTTP 411 error:

Ensure Content-Length Header is Preserved:

In the HTTP settings of your Application Gateway, ensure that the "Override backend path" option is not enabled, as this can sometimes cause headers to be dropped.

Verify that the "Request timeout" and "Response timeout" settings are appropriately configured.

Configure Mutual TLS:

Ensure that the Handshake Listener is configured to require client certificates for mutual TLS, which involves setting up the appropriate SSL policy and uploading the client certificate to the Application Gateway.

HTTP Settings Configuration:

For BootStrap-Listener, you need to select the HTTP protocol since you are proceeding without authentication. However, your configuration currently has HTTPS please try to change the protocol to HTTP.

In the HTTP settings for the Handshake Listener, ensure that the "Use custom probe" option is enabled and configured correctly to help maintain the connection and avoid the 411 error.

Ensure that the "Enable HTTP2" option is disabled if your backend does not support HTTP2.

Backend Pool Configuration:

Ensure that the backend pool for the Handshake API is correctly configured with the appropriate backend servers and that the health probes are set up to check the availability of the backend servers.

Additional Resources

For more detailed guidance, refer to the following resources:

Listener TLS certificate management in Application Gateway | Microsoft Learn

Enabling end to end TLS on Azure Application Gateway | Microsoft Learn

Tutorial: Create an application gateway with URL path-based routing rules using Azure portal | Microsoft Learn

If above is unclear and/or you are unsure about something add a comment below.

Please don’t forget to close the thread by clicking "Accept the answer" wherever the information provided helps you, as this can be beneficial to other community members.

Regards,

Ganesh
Ganesh Patapati 2,825 Reputation points Microsoft Vendor

2025-01-02T10:40:48.32+00:00

Hi Ganesh Chowdhary

Good day!

I wanted to follow up to see if you had a chance to review my response to your question about resolving the issue.

If you are still encountering any further issues, please feel free to reach out to us. We are happy to assist you.

I look forward to your response and appreciate your time on this matter.

If your queries have been resolved, please accept the answer by clicking the "Upvote" and "Accept Answer" on the post.

Regards,

Ganesh
Ganesh Chowdhary 0 Reputation points

2025-01-03T03:11:01.72+00:00
Hi Ganesh Patapati,

Thanks for the response. The details you provided we already went through.

the issue mentioned above was resolved by selecting the Redirection Type as a Temporary that was forwarding the required header and body without modification to the backend needed.

After performing the above steps we have a new issue, we have the below requests to be supported

bootStrap (POST method) to be supported without SSL Verification

handshake(POST method) to be backed with SSL Verification

pendingCnd (GET method) to be backed with SSL Verification without Redirection(as the client do not support redirection for GET requests)

With the current rule, we have all requests(except bootStrap) to be redirected to another listener for SSL verification. With Client code restrictions, GET requests can not be redirected to any other host.

Could you please let us know Is any way we can support the above requirement with Application Gateway
Ganesh Patapati 2,825 Reputation points Microsoft Vendor

2025-01-07T19:10:04.78+00:00
Hello Ganesh Chowdhary

We appreciate your Patience!

If you look at bootstrap listener, it doesn't have an SSL profile where without SSL Verification it should be supported.

During the handshake process, there is an SSL profile enabled, so it should align accordingly.

Could you please clarify what you mean by "PendCnd" and provide more details on what you refer to as "another listener"?

Could you please provide more details about your setup and configuration? Specifically, what are you trying to achieve? Are you referring to listeners or rules at Bootstrap?

Additionally, whenever you hit a listener, you need to go through mTLS in Azure Application Gateway.

Looking forward to your response and appreciate your time on this.

Regards,

Ganesh
Ganesh Patapati 2,825 Reputation points Microsoft Vendor

2025-01-08T12:16:07.46+00:00

Hello Ganesh Chowdhary

I wanted to follow up to see if you had a chance to review my response to your question.

Please let us know if it was helpful, and do not hesitate to reach out if you have any further queries.

If your questions have been resolved, kindly accept the answer by clicking the "Upvote" and "Accept Answer" on the post.

Regards,

Ganesh
Ganesh Chowdhary 0 Reputation points

2025-01-08T16:13:55.0633333+00:00

Hi @Ganesh Prajapati

We have primary listener device-to-cloud.com without SSL Profile Enabled.
and also we have a connect-api-dev listener that validates the SSL profile and forwards traffic to apim.

we have attached the device-to-cloud.com listener to the rule having below Path-based routing and redirect rule configured.

here, we have /api/bootStrap* that has to work without certificates(mTLS)

and other requests need to support mutual authentication by validating certificates against the configured SSL profile so we have redirected them to connect-api-dev listener having SSL profile enabled .

With this rule, we are facing issues for /api/pendingCmd* APIs throwing the below error,

<html> <head><title>307 Temporary Redirect</title></head> <body> <center><h1>307 Temporary Redirect</h1></center> <hr><center>Microsoft-Azure-Application-Gateway/v2</center> </body> </html> * Connection #0 to host device-dev.insg-pegasus.com left intact

/api/pendingCmd is GET Type of Request for which it do not support auto -redirection ,it is not enabled.

If we add it in the path-based rule ,

The API works fine but it does not validate the SSL Profile. APIs are working without certificates.

How we can support the /api/pendingCmd GET API with validating mTLS without HTTP Auto Redirect .with our existing requirements
Ganesh Patapati 2,825 Reputation points Microsoft Vendor

2025-01-10T11:55:24.04+00:00

Hello Ganesh Chowdhary

We appreciate your Patience!

I wanted to follow up to see if you had a chance to review my response to your question.

Please let us know if it was helpful, and do not hesitate to reach out if you have any further queries.

If your questions have been resolved, kindly accept the answer by clicking the "Upvote" and "Accept Answer" on the post.

Regards,

Ganesh

1 answer

Ganesh Patapati 2,825 Reputation points Microsoft Vendor

2025-01-09T16:10:23.0966667+00:00

Hello Ganesh Chowdhary

We appreciate your Patience!

If we add it in the path-based rule, The API works fine but it does not validate the SSL Profile. APIs are working without certificates.

you should not use in the Path based rule; you should have to be used in the redirect rule that's it. If you want MTLS to happen then you should not use path-based rule, you redirect to the listener which has MTLS, where only listener as MTLS.

In this diagram, when using a listener with no MTLS, if you are implementing a path-based rule, it will directly route through the backend without MTLS. This flow respects the listener configuration. If redirection occurs, you will encounter another listener with MTLS, as shown in the diagram, which will route to a different backend that supports MTLS.

However, in this case, the traffic first goes to the app gateway listener, which then directs it to another listener. Ideally, the flow should route directly to the backend via the path-based rule. Instead, it goes to the client, then to another listener where a 307 redirect sent by the app gateway is handled by the client. This does not work because path-based rules only respect listeners with MTLS configuration.

NOTE: Path based rule will respects its listeners MTLS better go with redirection and make your clients supports 307.

If above is unclear and/or you are unsure about something add a comment below.

Please don’t forget to close the thread by clicking "Accept the answer" wherever the information provided helps you, as this can be beneficial to other community members.

Regards,

Ganesh
Please sign in to rate this answer.
Ganesh Patapati 2,825 Reputation points Microsoft Vendor

2025-01-13T08:36:05.4433333+00:00

Hello Ganesh Chowdhary

We appreciate your Patience!

I wanted to follow up to see if you had a chance to review my response to your question.

Please let us know if it was helpful, and do not hesitate to reach out if you have any further queries.

If your questions have been resolved, kindly accept the answer by clicking the "Upvote" and "Accept Answer" on the post.

Regards,

Ganesh
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

Facing Issues with Mutual TLS Configuration for Specific Routes in Azure Application Gateway

1 answer

Your answer