Need to remove .azurewebsites.net cert from my App Service custom domain

Michael Dunkel 0 Reputation points
2024-05-01T16:49:00.6666667+00:00

I have an App Service servicing an API for a device with older, finicky SSL requirements. It can't accept multiple SSL certs on a domain and recognize the appropriate one to use, the domain has to only have the single cert it expects.

In addition to the default *.azurewebsites.net domain we have created two custom domains. Each of them has a cert assigned to them with the SNI SSL binding type. The issue is that while each custom domain has the appropriate bound cert, according to the devices (and to SSL Labs server test) both of the custom domains are also returning the *.azurewebsites.net ssl cert as well.

Originally we only had a single custom domain, and the cert was attached with an IP binding rather than SNI, and that kept the default cert from being passed on. However when we created the second custom domain the IP-based binding from the first domain was returned to the second domain. In order to ensure that each cert stayed in it's own domain we had to bind them as SNI SSL, but that leads to the default cert coming through as well.

Is there a way to restrict this default cert from the custom domains using App Service configuration? I would prefer not to create additional App Service Domain resources to wrap my App Service.

Azure App Service
Azure App Service
Azure App Service is a service used to create and deploy scalable, mission-critical web apps.
7,408 questions
{count} votes

2 answers

Sort by: Most helpful
  1. ajkuma 24,971 Reputation points Microsoft Employee
    2024-05-03T12:25:31.99+00:00

    @Michael Dunkel , Based on my understanding of your questions description,

    The  *.azurewebsites.net domain name and the certificate is provided and owned by Azure.

    I understand the requirement of removing the default domain, but there is no way disable it. You could instead accomplish this by adding a rewrite rule (Or Redirect rule).

    A rule to detect if the user has accessed the website using the Azure default domain and issue a HTTP 301 or 403.  

    Just to highlight, by default, http://yourdomain.azurewebsites.net works even with custom domain added, and the site admins aware about the URL can access, but typically end users would not access this URL directly (unless explicitly shared).

     

    Reference on other approaches outlined in the similar discussion threads:

    I'd posted an answer on similar discussion thread:

    More info:

    App Service *.azurewebsites.net TLS Cert Renewal for Web Apps, Functions, and Logic Apps (Standard)

    Kindly let us know if my understanding is correct, or please share more details about your scenario/requirement.


     If the answer helped (pointed, you in the right direction) > please click Accept Answer - it will help users to find the answers quickly.


  2. ajkuma 24,971 Reputation points Microsoft Employee
    2024-06-04T04:32:54.6933333+00:00

    Thanks for sharing the insights, Ben Gimblett

    To provide an update:

    Couple of things to check:

    1. Review -The certs to be deployed correctly so you can see them from the client
    2. Check - The device you are using as a client is capable of using an SNI extension

    Additionally,

    If the device does not send an SNI header, the following workarounds can be considered:

    • Use an app per host with IPSSL, all on the same plan (basic tier or higher). This can be achieved either by deploying a duplicate of the code for each host or by proxying to a common instance.
    • Use Azure API Management (APIM) as a proxy. APIM can handle clients that don't send an SNI header by allowing you to specify a default binding (for more details, see here).
    • Use Azure Application Gateway V2 as a proxy. Application Gateway V2 responds deterministically when an SNI header is not sent (for more details, see here).

    Note:

    When proxying, it’s better to keep the same host header end-to-end instead of rewriting it.

    Avoid using both IPSSL and custom SNI with App Service due to a certificate caching issue.

    0 comments No comments