I am currently working on an .NET 5 & SignalR application and in localhost everything seems to be working fine. When I try to deploy it to IIS pre-production Server which doesn't have a SSL certificate configured, pages other than Login are showing the message "This site can’t provide a secure connection". In the login page from the browser console I can see that most of me javascript and css files aren't loaded with the error "Failed to load resource: net::ERR_SSL_PROTOCOL_ERROR". Also from what I can see after user logs in, the request is redirected to Https.
I have removed app.UseHttpsRedirection(); from the Startup and disabled SSL in the Debug properties of the application. That seems to be a wired behavior because I used to deploy applications in .NET CORE before and didn't have these kind of problems. is there any way around this problem, except configuring an SSL certificate?
From the suggestions in server fault, configuring a self-signed certificate provided by IIS itself seems to be the problem solver. Still I don't get why the application was making that https redirection, but anyways in case someone else has this kind of issue.
Related
I have a Website that runs on a web farm (4 servers) behind a load balancer. The load balancer is the one that has the ssl certificate for https and decides to what server the requests go to.
In the code for the website, using .net Core I have in the startup.cs file logic in the Configure method to force the https redirection with app.UseHttpsRedirection(); So when we access the site without https the .net core permanent redirect the user to the https version (this is importand bc the web app is a PWA, so we need it for use service worker)
Imagine the url to access the website is https://production.website.com, again if the user try to go to http://production.website.com, it will redirects to https version. But you can also access each server in the web farm directly using these subdomains http://prod1.website.com, http://prod2.website.com, http://prod3.website.com, http://prod4.website.com (we have this set bc we want to test individual servers in case a deployment error happens on a specific server).
The problem is, bc the ssl certificate is in the load balancer (production.website.com domain), when you try to go directly to a individual server (prod1, prod2, prod3 or prod4) the .net core will redirect it to the https version and that server doesnt have a ssl certificate and the user will see an error on the browser, so we need a way to control that with a condition. So what the problem is? that at the startup.cs code we dont have access to the site url bc we dont have a request yet, I have research a lot and some workarounds that use to work in the past now with .net core 3.1 dont.
So how I can make that the code in the configure method doesnt force a https redirect if the users is accessing the individual servers and not the main domain for the web site?
I tried to setup automatic Let's Encrypt certification for a domain using this libray
It is easy to setup and I hosted it in IIS.After some errors couldn't make it work.
Finally I tried running app with Kestrel as end server, without IIS and i automatically got certificate and everything worked fine.
But my requirement is IIS hosted application because I already have some applications hosted on IIS all of them behind port 80/applicationName/
First problem I came upon is and also my first question: How can I even get to application using https(to auto get certificate) when I can't add IIS binding without certificate?
I assumed I must UseHsts() and UseHttpsRedirection() so I added it to startup of my application.
After some time and few different combinations of settings I got it work partially.
My application got certificate from LetsEncrypt and reported no errors, but when I access it in browser on http I get redirect to https and nothing there.(Still no binding for https in IIS).
My second question would be: How to properly configure https redirection from IIS to Kestrel in order to use my automatically acquired certificate?
create a dummy certificate in IIS, assign it to your site, save.
Go into IIS again and delete that certificate, if you check your bindings you'll find it as https, but certificate is empty.
Thanks
I have a blazor server-side application (netcore 3) which uses authentication through OpenID / Okta.
I started testing it through IIS, and running it as a regular website worked just fine.
But, I need to run it through a reverse proxy due to the rest of our setup, and after I set that up the blazor site no longer functions.
Our reverse proxy is simple, just takes a url (https: //subdomain.domain.com), and routes it internally (http: //localhost:8093). There are other sites connected here, this was just an example.
I managed to get all the resources (css, js, images) working correctly by adding the "app.UseForwardedHeaders", but I am still having an issue with Authentication.
For Authentication, it's setup with services.AddAuthentcation, and AddOpenIdConnect, which is triggered by an MVC call to Account/Login, that issues the HttpContext.ChallengeAsync.
Running the application standalone, or in it's website, the Login works, and redirects to Okta (https: //oktadevurl.com/oauth2/default/v1/authorize?parameters).
Through the reverse proxy, this url becomes relative to the Proxy address (https: //subdomain.domain.com/oauth2/default/v1/authorize?parameters) which is incorrect.
I've double checked the forward headers, and OpenId / Okta settings. I'm looking for anyone who has had this issue before and could point me in the right direction on how to get the absolute urls working from blazor through the reverse proxy.
Thanks.
I was able to solve this with one little checkbox is ARR:
In IIS Manager, Select the current server (not the website), open Application Request Routing, and on the right hand column there will be an option Server Proxy Settings. There you will see "Reverse rewrite host in response headers" option. If that is checked - uncheck it and your problem should be solved.
I have setup IBM MobileFirst 7.0 with IBM HTTPServer. HTTPServer only listens for SSL traffic on 443 (no requests over http on port 80 are being processed). The plugin-cfg.xml is directing the /appcenterconsole URLs to the WebSphere Liberty server running the MobileFirst app.
At first, the App Center console loaded and I could login, but any calls to /appcenterconsole/services/* were getting a certificate chain error. I fixed this by adding the http server's certificate to the Liberty keystore. After executing this change, the behavior changed such that on login to App Center, the user immediately receives a 'Your session has expired' message and is sent back to the login page.
Why is my session getting lost? The HTTP server has a JSESIONID for requests to /appcenterconsole/*.
Can the HTTP plugin send the traffic over http to the Liberty server to avoid the SSL chain issue?
This looks like an SSO (Single Sign On) problem. There are two web application, AppCenterConsole and AppCenterServices, and both require authentication, hence they should be set up with SSO. It seems you reach the AppCenterConsole but not the AppCenterService.
Liberty has SSO by default, but if you are using multiple servers, ensure that you have followed the instructions Configuring LTPA on the Liberty profile in the Websphere Liberty Profile documentation.
Alternatively, you can set the JNDI property ibm.appcenter.ui.cors to false for the AppCenterConsole. This will avoid the redirection of requests from the AppCenterConsole to the AppCenterService. If it doesn't already fix the problem, then at least it will produce a better error message with a stack trace that points to the real problem.
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?