Establishing HTTPS with multi sub-domain instance.

Comments

8 comments

  • Official comment
    James Vidler

    Hi David,

    If you are having issues setting up redirects in the web.config using the rewrite rules. Then, you can add redirects within Agility using URL Redirections and "external link" being checked.

    From: https://help.agilitycms.com/hc/en-us/articles/360014238752-Forcing-your-Site-to-Load-over-HTTPS-with-Redirects

    Adding Wildcard Redirects in Agility

    In Agility, navigate to Settings > Url Redirections and add the following redirect rules:

    1. Origin = http://{your-domain}.com, Destination = https://{your-domain}.com
    2. Origin = http://your-domain}.com/*, Destination = https://{your-domain}.com/* 

    After adding the redirects, any page requests matching that domain will be redirected from HTTP to HTTPS. 

  • David Zakrzewski

    That's all well and good but now I'm getting "Not Secure" without any debugging data, basically the default error page you see when errors not detailed because of the web.config and another sub-domain is throwing a "The site is down for maintenance..." page.

    I've reverted everything but the default site. That one works.

    Thoughts?

  • James Vidler

    Hi David,

    I would look at the Web Logs to see what error might be occurring. Or, you can temporarily turn off custom errors in the web.config. 

    In theory, adding Redirects through Agility shouldn't cause any issues like this, but there could be some underlying logic in the application that is conflicting with this.

  • David Zakrzewski

    The only error I'm seeing repeatedly throughout the logs over the past is: System.IO.IOException: The process cannot access the file 'D:\Home\AgilityLogs\TestWebsiteConfiguration.tmp' because it is being used by another process.

    Nothing indicates the error that I'm looking for.

  • James Vidler

    Hi David,

    That seems to be from an App Service (I can tell from the D:\ drive), not the intended VM host target. Ensure you are checking the weblogs for the VM and not the website ending in *.azurewebsites.net. - I believe this is a separate hosting environment and not related to the subdomains you are trying to setup HTTPs on.

  • James Vidler

    It looks like you have an error within your application. I think you need to run the site locally to really figure out what is going on. Here's what I would recommend:

    1. Deactivate the production syncing web servers - this will ensure any changes you make to Agility Url Redirections won't sync to production, this will also mean that editors won't be able to publish content during this time.
    2. Add your Agility Url Redirections for the other domains
    3. Run the site locally using IIS (not IIS Express) and install the certificate locally and add the headers for your domains you are testing
    4. Update your local hosts file on your computer to hijack the DNS for the domains you want to test, so that requests to the domains get routed you your localhost (127.0.0.1)
    5. If all is well, you should be able to reproduce the error and debug what is happening
    6. If you resolve the issue with a code update, then you can deploy your code update, then "Activate" your syncing web servers again to have the Url Redirection rule sync to production. If you can't resolve and need more time, then you can delete the Agility Url Redirection rules you just created and re-activate the syncing web servers
  • David Zakrzewski

    I'll give it a try but the small problem is, I don't have the source code.

  • James Vidler

    Oh, well you could still run the site locally by setting the DevelopmentMode=True in the web.config I suppose. However, your ability to debug probably won't work so well. That being said, it will give you an easy test environment locally to play around with things. I would recommend trying to get access to the source code in order to really figure out what's going on.

     

Please sign in to leave a comment.