locked
Publish internal website with AAD Application proxy RRS feed

  • Question

  • Hi,

    I'm trying to publish an internal website by using AAD Application Proxy with a custom domain with a wildcard certifcate. The website is running in IIS on a VM that's running in Azure. 

    When I publish the website I'm not able to browse the specific site, it gaves me a certficate error (*.msappproxy.net is missing) and finally a 404 error, but when I go this website from a Azure VM it works without any problems.

    We use a split DNS solution and created the CNAME records both on premise as with our internet provider. Can someone explain me why the site is working perfectly based from a Azure VM and not from a internal client or even a 4G connected device.

    Any help would be great!

    regards,

    Michiel

    Tuesday, January 9, 2018 12:14 PM

Answers

  • Found out (ran nslookup -debug) that there was a mismatch regarding the CNAME record at the ISP site. 
    • Marked as answer by Chiel Dekker Monday, January 15, 2018 10:16 AM
    Monday, January 15, 2018 10:16 AM

All replies

  • Have you followed the steps mentioned in the document to Configure a Custom Domain ?

    To update the certificate for a given application, navigate to the application and follow steps 5-7 in the document for configuring custom domains on published applications to upload a new certificate. If the old certificate is not being used by other applications, it is deleted automatically.

    ---------------------------------------------------------------------------------------------------
    Do click on "Mark as Answer" on the post that helps you, this can be beneficial to other community members.

    Tuesday, January 9, 2018 8:16 PM
  • I Ray, I did follow the steps you mentiond, but still the problem exists. I just created a Azure support ticket and wait for that. Thanks for your help and if it get fixed I will post the fix.

    regards,

    Michiel

    Wednesday, January 10, 2018 4:05 PM
  • Found out (ran nslookup -debug) that there was a mismatch regarding the CNAME record at the ISP site. 
    • Marked as answer by Chiel Dekker Monday, January 15, 2018 10:16 AM
    Monday, January 15, 2018 10:16 AM