I have 2 Windows 2012r2 Servers (Dev and Production) both running IIS 8. Both were configured identically as far I as know. I am in the process of installing wildcard certs on both of them.
I installed the cert on my Dev server and it's working. One thing that surprised me though was that I didn't have to add any additional bindings to any of my site configs (eg: I didn't add https/443) and just simply changing http to https in the browser is working, and showing the cert. Why is that?
My main question though is that on my Production server, before importing the wildcard cert, I tried simply changing the url for a couple of the domains I host from http to https in a browser to see what the result would be. When I do this I'm getting a redirect loop for all https tests. ???
I don't have any https URL Rewrites configured so I don't know what the cause of the redirect loop is. It does it for all sites on this server when trying to load it using https.
example:
http://mydomain.example.com (works)
https://mydomain.example.com (redirect loop)
Safari says, "...redirected you too many times. ERR_TOO_MANY_REDIRECTS"
Chrome says, "Too many redirects occurred..."
Additionally, if I load http://localhost on the server itself it works. If I load https://localhost I get an error, "Not Found - HTTP Error 404".
I should add that this Production server is behind an F5 Load Balancer so that could be playing into this behavior as well.
The cause of the redirect loop for all sites on the Production server was an irule on the F5 LB, that shouldn't have been there, that was looping port 443 back to itself. HTTPS for all sites worked after the irule was removed.
With regards to the Dev server and https sites working without having to add a binding. I also discovered that the F5 was configured to handle certs with a wildcard cert so local certs weren't even required. The data center team didn't communicate to me that the LB was configured to handle certs for these servers.
Related
I am injecting some script tags in a website, with source such as http:localhost:3000/css/my-page-css.css . While its working on almost all sites, there's this particular website that is somehow sending all my http requests as https. How do I handle such a case?
I have configured an https server also on my nodejs app which listens to port 8443 and http listens to 3000. But, when I inject my script tags, they have src URLS which point to port 3000. So even if I have an https configured on my nodejs app, it won't work since it would be listening to a different port.
You are using HTTP Strict Transport Security (HSTS)
Using the securityheader.com website on your URL, or Chrome Developer tools we see the following HTTP Header is sent back by your site:
Strict-Transport-Security max-age=7889238
This HTTP Header will be configured in your webserver and is a way of your webserver telling the browser "For the next 7889238 seconds only use HTTPS on this domain. If someone tries to use HTTP (either by typing or by clicking on a link) then automatically switch HTTP to HTTPS before you send it on to the server."
This is a security feature as currently the default (if a scheme is not explicitly given) is HTTP. This allows website owners to switch the default and, even strong that that, prevents it being able to be switched back.
HSTS is set at a domain level and it is not possible to have it on for one port (e.g. 443) but not for another (e.g. 3000) - it's either on for that domain or off.
If you really want to use HTTP then you need to remove this header and remove the remembered value of this header from your browser. While chrome allows you to do this by typing chrome://net-internals/#hsts in the URL and using the delete option, the easiest way to do this is to change the max age from 7889238 to 0, and then load the website again. And then remove the header completely.
This can be especially annoying for sites like localhost where you proxy requests and inadvertently set it for that dummy host name. You should see if your node proxy server allows you to strip off that HTTP header. Some might say it would be better if browser makers ignored HSTS for localhost, however I think it would be better if developers just stopped fighting HTTPS and used that even for development environments using a self-signed certificate that is added to your local trust store. This was you can avoid problems like mixed content, and also use features that are HTTPS only (including Brotli, HTTP/2, Geo Location...etc.) while developing (though some browsers like Chrome still allow these on http://localhost).
Alternatively set up a local DNS alias for each of your dev sites and use that with or without HTTPS as appropriate for the site in question.
I want to add a load balancer to an existing asp.net project using Application Request Routing. So I made myself familiar with the concepts and created a local test-setup:
IIS locally running on Windows 10:
Installed Application Request Routing 3.0 with Windows Platform Installer
Created server farm with following servers:
<test-server-name>.de (Microsoft 2012 R2 Server: contains the asp.net project)
www.google.com (just to see if load balancing and url rewriting works because I don't have two test servers available)
URL-Rewriting rule:
After typing localhost multiple times in any browser, I can see that load balancing (weighted round robin) is working fine. It's alternating between 1. and 2. website.
The problem I'm facing is a 404 Error on both websites.
I already tried the following:
Installing and enabling Failed Request Tracing Rules (on local IIS): URL Rewriting is working properly i think.
Failed Request Log for www.google.com: google drive, unzip and open xml in e.g. IE for better view
Create Server Farm without automatic creation of URL Rewrite rules
(selecting No and create own URL Rewrite rule)
Change "Managed Pipeline Mode"-setting of Applcation Pool from Integrated to Classic
Healthcheck on other Websites I have absolutly no clue why it's working on Git-websites and why facebook is returning a 400 error code.
Enabling/disabling proxy (IIS-Manager -> Application Request Routing Cache -> Server Proxy Settings...)
I don't know what i could do next, so I appreciate any help. Thanks.
Answer can be found here: https://forums.iis.net/t/1238739.aspx?Why+some+sites+return+HTTP+404+some+don+t+
Some websites simply don't support localhost as hostname, which is why localhost can't be found (error 404) e.g. on google.com
Detailed answer if link above is not working in future:
That is not an effective test.
What you are doing is sending the hostname of your request to the third party servers. Like Google.
So if your request is say http://example.com you are sending this to say www.google.com and the Google servers will likely reject this as you can see
Web server admins generally don't let themselves receive traffic from domain thet do not host.
If you sent a request to my servers IP with mysite.com I too would likely reject it. (Things get complex if you have wildcard sites and you allow all traffic through)
But simply showing that 404 page from Google means tour request hit there server so that implies ARR is working.
If you really wanted to test it this way have a local host file with www.google.com resolving to your servers IP. Set up a site with www.google.com as the hostheader and then you should see the correct info hitting Google. But there is no accounting for what 3rd party admins do on their side.
Need help with this odd issue.
I installed an SSL Certificated from GoDaddy for a site hosted on our server (lets call this example.com). This is a Windows 2003 Server with IIS 6 with several domains hosted on it. The SSL installed properly.
However, now if I type any url of a different domain (say example.org) hosted on this same server with HTTPS, I get the following error in Chrome:
Your connection is not private
Attackers might be trying to steal your information from
(for example, passwords, messages, or credit cards).
NET::ERR_CERT_COMMON_NAME_INVALID
Firefox will also give similar errors.
example.org has no SSL associated with it and there are no other SSL Certificates for any other sites either.
I am at a loss as to how ALL sites on the server are loading with SSL. Funny thing is that clicking on the link in browser error loads the Site to which SSL is assigned, but URL remains the same.
Ex. I type https://example.org (NO SSL Associated with this site) and type enter
I see the error above
If I click on Proceed to example.org (unsafe), it takes me to https://example.org but the content loads for domain example.com which has the SSL certificate bound to it.
I have checked Metabase for Bindings and seems clean.
I have deleted the SSL certificate and installed a fresh one issued from Godaddy
Tried deleting the site from IIS and recreating the whole thing but still no difference.
No other site has any host headers for SSL Port 443
Any ideas on how this can be resolved so that ALL Sites don't load on SSL? Thanks in advance.
Go to IIS Manager.
Open property page of website where you dont need SSL (example.org as mentioned in question) by right click on website and select properties.
Go to directory security tab
Click Edit button located in ottom section of tab.
Verify if very first checkbox called "Require secure channel(SSL)" is UNCHECKED.
I am hosting my public facing site at a shared host (Hostgator) with the domain pointing to the same. I also have my application hosted on a dedicated server with a different host. Both servers have their own SSL certificates installed.
Is there any way to edit the .htaccess file to do the following:
https://www.domain.com/CUSTOMER redirects to https://x.x.x.x/CUSTOMER while the browser still shows www.domain.com/CUSTOMER?
I'm vary of using frames due to the SSL ramifications. My domain registrar is Hostway and they do not offer URL masking/forwarding.
This can be done by making your server act as a proxy. Even if you have no access to the servers configuration you might be lucky that apaches proxy module is loaded: http://httpd.apache.org/docs/2.2/mod/mod_proxy.html
If so you can 'map' the remote site (IP) as if being served by your normal server.
Also apaches rewriting module can make use of that module by using the [P] flag in a RewriteRule.
Be sure you have a copy of that site on the different server, preverally with the same database, so you don't get in trouble with i.e. order numbers or user logins between http and https. The certificate server must be the web server for your SSL provided web content.
Take a look here foor further informations. "Google Search Result"
I recently moved servers and redeveloped the website at the same time. Previously all pages were served via https and I wanted to change this so only cart pages were via https. Also I wanted to clean up the url a bit. Old urls were:
https://secure.mydomain.com/onlinestore/index.php
and I removed the secure prefix and the subfolder so it is now:
http://www.mydomain.com/index.php
Problem is I wanted people who clicked on old links or bookmarks to be redirected to the new page. I got this working with htaccess. However the new SSL only covers the root domain and not the secure subdomain. So if someone clicks an old link it brings up "This Connection is Untrusted" before it can redirect. Works fine if i change https to http.
So what I want to know is if there is anyway I can force http instead of https before it checks the SSL cert.
Hope that makes sense!
The short answer is no. With conventional SSL, your web server doesn't even get to see the URL before certificate negotiation happens. It just sees a connection on port 443 and starts doing SSL negotiation. The browser then sees the mismatched cert and throws an exception.
However, more modern browsers and web servers (see Wikipedia for the list) support a TLS extension called Server Name Identification (SNI), which allows the client to send the hostname it's requesting before the server has to respond with a certificate. At that point you'll need to have certificates for both secure.mydomain.com and www.mydomain.com on that server, and it'll need to be configured to respond with the proper certificate.