Introduction
In my line of work, which often involves managing projects hosted on Azure and utilizing DXP platforms like Kentico and Umbraco, Azure Front Door has become an vital component of our setup. We are strong advocates of this service and have utilized its capabilities to enhance various aspects of our applications. A great example of this is the built-in Web Application Firewall (WAF) capabilities and protection against DDoS attacks.
However, a recent development has brought a new challenge to our attention, particularly concerning users who access our websites via Safari browsers. Interestingly, these users have reported encountering an unexpected issue. On occasion, they are met with a seemingly generic error message from Azure Front Door:
"Our services aren't available right now. We're working to restore all services as soon as possible. Please check back soon."
This issue is interesting because the Azure Front Door is configured in detection mode, with the aim of analyzing incoming traffic without actively blocking it. To determine the cause, a thorough analysis is necessary.
Root cause of the error
Investigating the issue proved to be somewhat of a puzzle due to its sporadic behavior. However, we managed to make progress by reproducing the situation on a Mac. During testing, we noticed something intriguing: when Safari displayed the "Our Services Aren't Available Right Now" error message, we also observed a "421 Misdirected Request" response in the browser. This helped guide our search for more information and led us to the following relevant post on Stack Overflow. This post introduced us to the concept of "Domain Fronting," a behavior inherent in Azure Front Door.
Essentially, domain fronting is a security measure in Azure Front Door that blocks certain HTTP requests. Specifically, if the host header of a request doesn't match the original TLS SNI extension, it can be blocked. Understanding this behavior shed light on the root cause behind the "Our Services Aren't Available Right Now" error experienced by Safari users and helped determine the next steps to be taken.
Hello, IT
Reaching out to Microsoft was a logical step that provided valuable insights into the problem's cause, especially regarding its connection to the way Safari interprets TLS mismatches. In the course of our communication with Microsoft, we discussed the possibility of disabling domain fronting, as mentioned in the Stack Overflow post, as a potential measure to address the issue. This collaborative approach helped us to gain a more comprehensive understanding of the problem and explore potential solutions.
It became clear that in our setup, the use of a multi-domain SSL certificate played a crucial role in the Safari-Azure Front Door relationship. The problem appears to be connected to how Safari interprets TLS mismatches and is not a bug within Azure Front Door. Microsoft suggested a potential solution, which involves using distinct certificates for each custom domain or considering the utilization of Azure Front Door managed certificates, incorporating individual Subject Alternative Names (SANs).
Fixing the problem
As a solution to the problem, we ultimately opted to use a separate SSL certificate for each domain hosted on the platform. Luckily the SSL certificate management can be automated within Azure Front Door. Initially, we encountered difficulties in provisioning the SSL certificates. Once again, Microsoft came to the rescue.
To provision the SSL certificates, it's important that the domains are mapped to Azure Front Door via DNS. Additionally, you need to either add "digicert.com" to the CAA (Certification Authority Authorization) record or remove the CAA record altogether (leaving it blank and unlinked to any CA). Once this step is completed, Digicert can seamlessly issue the necessary SSL certificates.
Conclusion
In this article, you've been able to read about how we went from a vague browser-specific issue to the eventual solution by implementing individual SSL certificates for the website domains in question. Along the way, it provided us with numerous insights into the capabilities of Azure Front Door. Hopefully, this article will help you if you encounter the same issue. If you have any tips or suggestions, please feel free to share them in the comments below.
Top comments (1)
Glad you figured this one out! That was a deep dive.
I've used Azure Front Door Managed Certificates in the past year and they worked quite well, were convenient to setup and configure, and didn't require additional IT oversight after allocation and assignment.
My overall experience with AFD as a reverse-proxy was very positive, but I typically used Cloudflare as a WAF.