Share via

Azure AAD B2C requests to API via Azure Front Door resulting in HTTP 412 (Domain Fronting)

Jason Lee 181 Reputation points
2023-03-16T21:59:57.69+00:00

Hi,

We have an Azure Active Directory B2C tenant where we have custom policies that send requests to an API. Requests to this API go through Azure Front Door. Our APIs are hosted in Azure Container Apps. We have had this integration working perfectly fine for months and we haven't really changed our Front Door configuration in a couple of months. All of a sudden today, Front Door in one of our environments started rejecting requests from Front Door with an HTTP 412 error.

After some research, we discovered Front Door started rolling out a security feature to prevent "Domain Fronting" a year ago. Documentation states we send a request to MS support to disable protection from Domain Fronting which we plan to do before we experience more problems. I'm reluctant to disable a security feature, especially when we do not know the root cause. Our B2C custom policies only ever send API requests to a single domain since all our APIs are behind Front Door.

Does anyone have any idea why this problem would have happened all of a sudden? Does anyone know how to avoid this problem? It is impossible for us to diagnose this problem as the network traffic is between AAD B2C and Front Door, so we can't inspect network traffic to see the SNI and HTTP host header of the requests.

Looking at the Front Door logs (AzureDiagnostics table) the host name (hostName_s) is exactly what we expect. As we have no visibility into traffic between AAD B2C and Front Door, we cannot see the SNI to confirm there is indeed a mismatch. Given the logs say the HTTP host name is correct, I suspect B2C is establishing an SSL connection to the wrong SNI but there's no way for us to confirm this.

Thanks in advance for any assistance!

Azure Front Door
Azure Front Door
An Azure service that provides a cloud content delivery network with threat protection.
634 questions
Microsoft Entra ID
Microsoft Entra ID
A Microsoft Entra identity service that provides identity management and access control capabilities. Replaces Azure Active Directory.
20,630 questions

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. GitaraniSharma-MSFT 49,401 Reputation points Microsoft Employee
    2023-05-19T13:31:38.5966667+00:00

    <<<UPDATE FROM SUPPORT CASE>>>

    Hello @Jason Lee ,

    I understand that you have an Azure Active Directory B2C tenant with custom policies that send requests to an API via Azure Front Door, but these Azure AAD B2C requests to API via Azure Front Door are resulting in HTTP 412 error.

    It looked like Front Door has enabled the block for ‘domain fronting’ behavior.

    Refer: https://azure.microsoft.com/en-in/updates/generally-available-block-domain-fronting-behavior-on-newly-created-customer-resources/

    If your application is sending a mismatch between the TLS SNI extension and the host header inside the HTTP session, then that request will be blocked with a 421 response from CDN/AFD.

    But we were not sure why your Front Door started rejecting requests all of a sudden.

    We know that when Front Door blocks a request due to a mismatch:

    • The client will receive an HTTP "421 Misdirected Request" error code response.
    • Azure Front Door will log the block in the diagnostic logs under the "Error Info" property with the value SSLMismatchedSNI.

    However, it was not possible for you to diagnose this problem as the network traffic was between AAD B2C and Front Door, so you couldn't inspect network traffic to see the SNI and HTTP host header of the requests.

    Looking at the Front Door logs (AzureDiagnostics table) the host name (hostName_s) is exactly what you expected. You suspected that B2C is establishing an SSL connection to the wrong SNI but there was no way for us to confirm this, as we had no visibility into traffic between AAD B2C and Front Door and we cannot see the SNI to confirm there is indeed a mismatch.

    So, we created a support request and for further troubleshooting.

    The support team looked into the internal logs and confirmed that all the 421s are being generated on a specific domain which are authentication calls but not all calls for auth on this domain were failing.

    After looking further, they found that the SNI/hostname mismatch might be due to improper configuration on the AAD site for domain used for application site config and identity provider settings.

    You performed a tweak on the recommended setup to get this config going. When configuring the B2C config on the environment, you changed your app and API calls to not work with the auth- domain but with the domain configured only. Later, you found that the 421s stopped. But you wanted to know the r

    At the end the support team shared the below root cause for this issue:

    Root Cause:

    Wildcard certificates causing SNI session being reused which is triggering SNI mismatch error on calls from AAD B2C.

    Resolution:

    Replaced wildcard certificates with single name indicator certificates and the issue was fixed.

    Kindly let us know if the above helps or you need further assistance on this issue.

    Please "Accept the answer" if the information helped you. This will help us and others in the community as well.

    0 comments