We're working on an integration that will allow and external 3rd party too call our APIs..
The third party controls the governance of the how our APIs should respond, and have stipulated that we must return an HTTP 403 error when the client calls with a missing, invalid or expired mTLS certificate.
Note, that this is not in a browser scenario. We have a technical service of some description outside out network calling into an API endpoint exposed by our system.
We have implemented an mTLS listener on an Azure App Gateway, and have observed that the default behaviour for this is to return a 400 Bad Request.
We are of the view that this cannot be reconfigured, so can i just check this is a common understanding?
More fundamentally though, I'm looking to understand if there are challenges we should highlight in respect of industry standards for HTTP Error codes in this instance.
Fundamentally, sending a 403 here feels wrong, but I'm keen to add some evidence to that feeling.
You are right, when implementing mTLS on an Azure Application Gateway, the default behavior for handling issues related to client certificates (such as missing, invalid, or expired certificates) typically results in an HTTP 400 Bad Request response. This is a standard behavior of the Application Gateway when it cannot properly negotiate mutual authentication as per HTTP response codes - Azure Application Gateway | Microsoft Learn
Returning an HTTP 403 Forbidden status code in this scenario may not align with standard practices. The HTTP 403 status is generally used to indicate that the server understands the request but refuses to authorize it, which is not the case when the client certificate is missing or invalid; instead, it is more appropriate to return a 400 status indicating a bad request due to client-side issues.
References-