I have couple of questions regarding IIS configuration.
When I enable HTTP redirect in IIS and use http://localhost/SubApp it's redirected to https://localhost/SubApp, but when it's http://localhost/service.svc it's not redirected to https://localhost/service.svc.
Also with redirect enabled URL like this https://localhost/test.html is not opened, I see message
Can’t reach this page. Make sure the web address https://localhost is correct.
Content of file very simple: <html><body>test html</body></html>.
However when HTTP redirect disabled I can open this URL. I have self-signed certificate.
Config for HTTP redirect is
<httpRedirect enabled="true" destination="https://localhost" exactDestination="false" childOnly="false" httpResponseStatus="Permanent" />
So, questions are:
Why *.svc is not redirected to HTTPS protocol?
Why https://localhost/test.html can't be opened with enabled http redirect?
Does it all mean just use url rewrite module and get rid of redirect configuration?
After tests we have found out that the only possibility to use HTTP redirect (from HTTP to HTTPS) is:
Configure HTTP binding for the main site so port changed from 80 to 81. Also, port 81 is not visible from outside
Add new website with HTTP binding to port 80, this site has empty WWWRoot
Add HTTP redirect to this new empty website so it redirects to HTTPS of our main site.
In this case HTTP redirect works fine.
My aim was three-fold
to use a domain name in the address bar without www
to auto-redirect from HTTP to HTTPS without fail or issue or the need to accept certificates in the browser of any kind
simple failsafe security. if google can do it why can I?
The idea of using a 'smoky' port in the previous post was smart. While using port 80 I was constantly getting the blue IIS welcome page and the http protocol. The fake port seems to force the asp.net web page to actually read the redirection code in the web config. I changed all my http bindings to port 81. Added to that the rewrite url codes in the web.config shown below.
Another important thing to test is turning OFF the 'Required SSL' as one post indicated it may conflict with IIS Rewrite URL (any conflict that doesn't show an error can be a major headache). Prior to turning the IIS 'SSL Settings' 'Required' switch off and leaving just 'Ignore' as checked ANY combination of Rewrite URL from the hundreds of posts or walkthrough setups seemed to fail (eg this was specific to IIS10 Win 2016 but probably the same all previous IIS's).
It was also important during testing to ensure requests are outside your Lan if hosting from a Static IP. Just use your mobile hotspot and a number of browsers from your tablet (eg samsung, brave, mozilla, edge etc) to see responses of each. Part of the reason for this was based on the implementation of TLS1.2 and disabling of ALL other protocols and ciphers.
Finally don't forget to constantly delete cookies / history prior to testing page loads. In some cases a 'wipe cache partition' on an android removes any temporary files that may be causing an issue with the device (especially during testing).
This issue can be a nightmare as things that are supposed to work absolutely don't work, even though the logic is 'bulletproof logical'.
Even with all these things considered and tested, there is a good chance it won't work in some browsers... it just refuses to move from the
h*tp://domain.com
IIS welcome page... eg edge, brave, etc
Sa sample rewrite with 3 rules, as per instructions from a popular ssl site
<rewrite>
<rules>
<rule name="HTTP to HTTPS redirect www" stopProcessing="true">
<match url="www.domain.com"/>
<conditions>
<add input="{HTTPS}" pattern="^OFF$"/>
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" redirectType="Permanent"/>
</rule>
<rule name="HTTP to HTTPS redirect" stopProcessing="true">
<match url="domain.com"/>
<conditions>
<add input="{HTTPS}" pattern="^OFF$"/>
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" redirectType="Permanent"/>
</rule>
<rule name="Redirect Canonical HTTP to HTTPS" stopProcessing="true">
<match url="domain.com"/>
<action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}"/>
</rule>
</rules>
<outboundRules>
<rule name="Add Strict-Transport-Security when HTTPS" enabled="true">
<match serverVariable="RESPONSE_Strict_Transport_Security" pattern=".*"/>
<conditions>
<add input="{HTTPS}" pattern="on" ignoreCase="true"/>
</conditions>
<action type="Rewrite" value="max-age=31536000; includeSubDomains; preload"/>
</rule>
</outboundRules>
</rewrite>
even some page load code in C# asp.net may do nothing... but it was worth a try... maybe it is not possible in IIS land.
protected void Application_BeginRequest(Object sender, EventArgs e)
{
HttpContext context = HttpContext.Current;
if (!context.Request.IsSecureConnection)
{
UriBuilder secureUrl = new UriBuilder(context.Request.Url);
secureUrl.Scheme = "https";
secureUrl.Port = 443;
context.Response.Redirect(secureUrl.ToString(), false);
}
}
Related
I have .Net MVC 5 application currently running with url like http://www.example.com in production (Hosted in IIS on Windows server). Now we have requirement to change the URL path to like this http://www.example.com/app.
What will be the best approach to achieve this?
The best way is to create a subdirectory app in the root directory of your website and move your .Net MVC 5 application into the app folder, if you set the Default Document, you can directly access it via http://www .example.com/app to access.
In addition, if you just want to access the content of http://www.example.com by typing http://www.example.com/app in your browser, you can try the following rewrite rule:
<rewrite>
<rules>
<rule name="test">
<match url="app" />
<action type="Rewrite" url="http://www.example.com/" />
</rule>
</rules>
</rewrite>
I have external free MP3 file (non-coyrighted) URLs on an http web-site.
I want to let users play these mp3 urls from my HTTPS site written in ASP.NET MVC.
How can I convert these HTTP urls to HTTPS urls on (using some sort of proxy on IIS) the fly without affecting performance.
EDIT:
The http site hosting mp3 is not mine. It has different domain name from my https site and is hosted on some other server by someone else. Any request for mp3 url on the http site (not owned by me) should appear to come through an https site (either my https site or some other). I do not have control over the http site, otherwise I would have put SSL on that site.
Thanks,
Gagan
you need to bind https binding with SSL certificate and redirect all the request from HTTP to https.
for redirect, you could use below url rewrite rule in your web.config file.
<system.webServer>
<rewrite>
<rules>
<rule name="Force HTTPS" enabled="true">
<match url="(.*)" ignoreCase="false"/>
<conditions>
<add input="{HTTPS}" pattern="off"/>
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}/{R:1}" appendQueryString="true" redirectType="Permanent"/>
</rule>
</rules>
</rewrite>
</system.webServer>
For certificate configuration following link can be helpful: Enabling SSL on IIS
I have created two .NET applications having Azure AD authentication. I have deployed both of them on the IIS server with different ports for HTTP and HTTPS.
1st Application: Deployed on HTTP Port 80 and HTTPS Port 443 with the Redirect URL of app1.xyz.com
2nd Application: Deployed on HTTP Port 88 and HTTPS Port 9443 with the Redirect URL of https://app2.xyz.com:9443
While authenticating a user for 1st Application, Authentication flow is working fine where the user is redirected to Login Page and after successful login, the user is redirected back to the application URL.
Where authenticating a user for 2nd Application, Authentication flow is not working fine where the user is redirected to Login page and it keeps on looping infinitely on the login page.
Could anyone please share your comments/suggestions on the above issue?
As it is common issue may be you have not chosen a pattern syntax and so you using the default regular expression syntax on your web config file, On the fly which I am assuming the causes for an infinite loop. Though you have not share your web config file but you can try this:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="Add www" patternSyntax="Wildcard" stopProcessing="true">
<match url="*" />
<conditions>
<add input="{HTTP_HOST}" pattern="example.com" />
</conditions>
<action type="Redirect" url="http://www.example.com/{R:0}" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
Note: Replace your desired URL On Code.
For more information you can click here...https://blogs.msdn.microsoft.com/kaushal/2013/05/22/http-to-https-redirects-on-iis-7-x-and-higher/
This somewhat works, http://newdomain.com/link will redirect to https://www.newdomain.com/link. However, http://olddomain.com/link redirects to https://www.newdomain.com (losing the path).
<rule name="Enforce HTTPS and www.newdomain.com" stopProcessing="true">
<match url="(.*)" />
<conditions logicalGrouping="MatchAny">
<add input="{HTTPS}" pattern="off" />
<add input="{HTTP_HOST}" pattern="olddomain\.com$" />
<add input="{HTTP_HOST}" pattern="^newdomain\.com$" />
</conditions>
<action type="Redirect" url="https://www.newdomain.com/{R:1}" redirectType="Permanent" />
</rule>
I believe the code is correct, but it's not working when doing a domain to domain redirect. Something else in IIS is doing the redirect first and therefore not respecting this rule (probably never even getting to it).
This may not be so much of an IIS redirect question, but a question of what else could be causing this pre-redirect before this rule. I have no other rules that have anything to do with domains at all.
Any insight into this?
Thanks to #Dusan Bajic I figured it out.
I totally removed the redirect. When I did that, some of the redirects stopped working. However, the redirect from the old domain to the new domain still happened (and in the same way, removing the path). That allowed me to isolate the problem as outside of an IIS redirect.
Come to find out, the problem was with our load balancer. For the old domain, it was doing a redirect of its own, so the old domain never reached IIS. Once the load balancer redirect was removed, it then got to IIS and the above redirect which worked flawlessly.
So the solution to this was to remove the redirect and see if the redirect still happened. And if so, look at whatever is "up stream" that's doing the redirect. I didn't know our load balancer did redirects, but I do now!
Thanks for the assist Dusan Bajic
This question could be posted on ServerFault as well, however there is definitely a coding element involved due to the rewrite rules in my web.config. This is why the question does indeed have a home on SO.
I've recently deployed a website to a new server and have discovered that trying to access my site via www.example.com returns a 404 while example.com works just fine. I'm not sure if this is an IIS configuration issue or with the rewrite rules I've specified in my web.config.
I have not redployed the site without the rules shown below to see if they are indeed the issue. These rules were working fine while the site was hosted by DiscountASP.NET.
<rewrite>
<rules>
<rule name="Redirect to NON-WWW" stopProcessing="true">
<match url=".*"/>
<conditions>
<add input="{HTTP_HOST}" pattern="^www.rsolberg.com$"/>
</conditions>
<action type="Redirect" url="http://rsolberg.com/{R:0}" redirectType="Permanent"/>
</rule>
<rule name="Default Document" stopProcessing="true">
<match url="(.*)default.aspx"/>
<action type="Redirect" url="{R:1}" redirectType="Permanent"/>
</rule>
</rules>
</rewrite>
I've also confirmed with GoDaddy that there is a WWW cname pointed to #.
Working:
http://rsolberg.com
Not Working:
http://www.rsolberg.com
I would confirm that IIS has both host headers (rsolberg.com and www.rsolbeg.com) listed for your site. Without the www version requests will make it to the correct web server but IIS won't serve the correct site and may be returning a generic 404 instead. I don't think the redirect/rewrite is involved at all as no 301/302s are getting sent.
I have solved this problem earlier, just delete the earlier CNAME. And try adding a new one as below
www.rsolberg.com CNAME --> rsolberg.com
Ananth Ramasamy Meenachi www.msarm.com