I have setup load balancing server with Application request routing on IIS, it's working fine but I am facing issue with https requests, they are being redirect(301) and in post call it's losing the post data.
I have disabled SSL offloading but still the https post requests are failing and taking me to login page due to post data not being forwarded to ARR or something.
Thanks
for now, I have added * binding and that seems to be working, not sure why it doesn't work when I specify the domain name in binding. but it's sorted by problem so good for now, but will be better to know how it will work with domain name in the binding.
Related
I'm working on a website based on an apache server hosted on server1 The front end has to get some data from server1 but from others, APIs hosted on server2
I'm quite aware of the same origin constraint and jquery requests are blocked by the CORS security policy
It looks like creating a subdomain dedicated to API calls like https://api.server1 that is a proxy to https://server2 looks the most conventional way.
But I have no control over subdomain and for the moment I would use a specific URI on server1 like https://server1/api-server2 to access to my web services hosted on server2
I've tried several apache configurations (Redirect, proxipass, proxymatch, ...) but I just manage to make a redirection to https://server2, so I don't think it will be compliant with the Same Origin constraint.
Finally, I'm looking for an apache configuration that makes server1 redirect request and manage the response to/from server2 but that stays totally transparent for the webbrowser, webbrowser seeing only https://server1/* request in any case
Could someone at least give some Apache directive to make that based on URI (/api) or eventually sub-domain api.server1 ?
Thank you in advance for your help... I'm stuck :/
RV
An issue I have been experiencing is that once every ~50 pages I load in Google chrome on my website is that chrome gives me an error page saying SSL Protocol Error. I am using Flexible SSL and various webapps, like webmin, vestacp, boxbilling and a few mostly static websites. All of these are hosted by nginx, reverse proxying directly to webmin and vestacp. As for the other webapps, the static files are hosted by nginx, reverse proxying to apache2 for php.
I am not entirely sure it is a cloudflare issue yet, but it does (seem to) work normal making plain http requests directly to my server. Of course I'd be surprised if I got any SSL error when using http.
The server request is being proxied through CloudFlare, as long as it is proxied through CloudFlare this issue lies with CloudFlare and there is little you can do to fix it yourself.
I would raise a support request with them and explain the issue, they give preference to clients who pay the most first, therefore you might have to wait to get a response.
Does the new heroku endpoint ssl support having both http and https on a single domain?
I would like to serve some pages via http://www.mydomain.com and also serve profile pages via https://www.mydomain.com/profile.
With the old ssl I needed to create secure.mydomain.com for https but I would rather not do this if possible.
thanks
Yes, that's fine. All you're adding with endpoint SSL is a entry point in front of your actual app that supports SSL. HTTP can still travel through this just fine, but obviously won't be secure.
I have a client who wants to set up SSL on a new directory on their website. They already have one directory using SSL. BUT, when I go into IIS, even the current encrypted directory isn't set up to require SSL. And, when I set either the new or old directory to require SSL it returns and error page stating that I need to call the page over https (which I did), no matter what.
We are not running in a farm. This is a single web server with no load balancing or proxy that I know of. 443 is not blocked. The log files shows a request for the page over 443, but redirects to http. What could be handling the encryption?
ASP.NET 2.0 APP running on IIS 6.0.
Any help is appreciated.
Thx,
T
Your comment "The log files shows a request for the page over 443, but redirects to http" implies yours pages are being sent over port 80. If this is the case what makes you think your pages are being encryted?
Another thought - are you running any ISAPI extensions such as Helicon?
Is there anything wrong with configuring a webserver to map SSL traffic (port 443) to the same document root as normal traffic (port 80)?
Using the same document root for both http and https means you need to implement the following:
On each page that needs to be secure, there needs to be some application code that redirects the user to the https version if they somehow got to the http version (or to rediect the user to the login page if they have no session).
The login page always needs to redirect to the https version.
For pages that are accessible via both http and https, you need to set a canonical URL to ensure it doesn't appear like you have duplicate content.
Is there a better way to configure encryption of user account pages? Is there a best practice to separate website into HTTP and HTTPS sections?
It's not necessarily wrong to do this, but as your points 1..3 show, it introduces complications. It seems to me that setting up a separate document root might be a lot simpler than working around the complications.
In Internet Information Server 7.X you can define a "secure path" which is require to access with HTTPS and you can redirect the user to a user-friendly error page.
Maybe this can be a good solution to mix the document root and keep parts of the application secured.
Redirecting http automatically to https allows for man-in-the-middle attacks and is therefore not recommended. A man-in-the-middle could manipulate your HTTP traffic to send you to a malicious HTTPS site that resembles your HTTPS content.