What would be the best way to allow only HTTPS connections with a self hosted .NET5 webApi?
And how do I go about configuring an SSL Certificate (either real or self-signed)?
I've only used IIS deployments so I'm struggling to understand how to make a webserver I don't control use a specific certificate..
Related
Currently my application is under a load balancer (NetScaler) and it does SSL Offload, so my application run in http, but externally is on https. In IIS is bound only http:80. The load balancer use a certificate called *.mycert.com
Now I have to require for a client certificate for a specific folder of my application /Services, but the certificate is myPeskyCert so different from *.mycert.com. This is necessary because I have to respect how the client will call me.
Currenlty I'm following the following answers:
Can IIS require SSL client certificates without mapping them to a windows user?
What is the difference between requiring an SSL cert and accepting an SSL cert?
,but in this way my application:
I have to do ssl bridging, so I have to bind 443 on the web app
in this way ALL my application is presented as myPeskyCert
How do I have to handle IIS in order to present my application as *.mycert.com, but ask for myPeskyCert when the folder /Services is requested?
It's non possible, a certificate must refer to the entire site bound.
The solution is the following:
bound the application to two different url binding
on the balancer set one certificate or the other with ssloffload on the two different url
I am using Azure Cloud Service and it packs two Roles: ASP.net MVC and ASP.net Web API projects. My MVC project uses ports 80 (for standard http protocol) and 443 (for https). And my API project is using 8080 (http) and 8443 (https).
What I would like to do is to assign 8080,8443 and 443 to my API project, and to my MVC project keep 80, and assign some other port for https (for example 8444).
What I did is edited Endpoints under Roles' properties (as described above), and it worked, kind of.
What is troubling me still is that when in a browser I enter https://mypage.com I am taken to my API page and not my MVC web page.
So how can I fix this (meaning that I want both my MVC and API projects to be accessible trough port 443) Could having https://api.mypage.com for my API project fix this? If yes how can I configure my DNS (which is on GoDaddy) and Cloud Service to support https://api.mypage.com?
Application Gateway can do the routing for you -
You'll have 80 and 443/TCP for the outside world and then map that based on URL/subdomain to custom ports back to your WebRoles.
E.g.
example.com ---> 8080/TCP and 8443/TCP
api.example.com ---> 8081/TCP and 8444/TCP
More on that here:
https://learn.microsoft.com/en-us/azure/application-gateway/application-gateway-multi-site-overview
A pair of varnish or nginx boxes will pretty much have the same result with the added benefit of caching things along the way. Downside is that you'll have to do it in IaaS and that's the opposite of an elegant weapon for a more civilized age...
Sample config for varnish: Configure multiple sites with Varnish
EDIT
Actually you COULD do it in PaaS on App Service with Docker containers:
https://learn.microsoft.com/en-us/azure/app-service-web/app-service-linux-using-custom-docker-image
You know what, maybe it's time to move those services over to App Service as two different Web Apps, each listening on its own subdomain. If you don't need elevation and you don't do messy things like write to registry you should be fine and you could drop a locomotive-worth of complexity straight away.
It's a crazy time to be alive.
We have an intranet server that hosts many web applications / web services in various virtual directories all located under the default web site in IIS6. These all just use http connections on port 80 e.g. "http://ourintranetsite/applicationname" or "http://ourintranetsite/servicename" etc.
We have a new web service that we have deployed to a virtual directory under the default web site and it works fine using an http connection. One issue has arisen now that we are starting to use SharePoint Online. We want to be able to call this web service from some client site script on a SP Online page, but it is causing an issue because the SP Online page is using https, so it doesn't like calling a web service over http (IE just puts a warning message in the browser console, but Chrome refuses to make the call at all).
Is it possible to configure just the virtual directory hosting this web service to require an SSL connection rather than setting it at the web site level? We really don't want everything under the default web site to start requiring https, just this particular service. Obviously I could just tick the "Require secure channel (SSL)" option in the properties of the virtual directory, but from what I understand (I've not had to use SSL before), the default port for that will be 443 while the website is using port 80. Ideally we'd just like to be able to get to the service with something like "https://ourintranetsite/secureservice/..." while not impacting any of the existing http applications and services.
No it's not possible to assign a certificate to virtual directory, however when you add a cert to the website all it does makes the site brow sable over https but that doesn't mean that it has to be browsed only over https.
What I meant is you can have site to be brow sable over http and https. Add the necessary cert to the site and make sure you do not check "Require secure channel (SSL)" and it should be good to go.
We have an application built on ASP.NET MVC 1.0 which, once deployed, should be accessed with HTTPS. I tried few approaches for HTTPS but I have a few questions.:
My home page does not need to be Secured (HTTPS), but rest of the hyperlinks following it will be Secured.
I read about the action method attribute [requiresHTTPS] however I want to understand what happens to that tag during development on local machine.
In a development enviroment, how do I install a certificate on a dev machine/virtual directory to code and test my changes.
So this application is complex in nature and we have around 13 controllers and 50 action methods. This application will have information like Credit card numbers since we do accept payment through this website.
Thanks much !
If it is just about a few static pages of your application that don't need to be secured, I would strongly recommend to simply require SSL for everything by configuring two different sites in IIS, one for the actual page only on port 443, one on port 80 with a permanent redirect.
Advantages:
Your application and code doesn't have to know anything about SSL, and you don't need a SSL certificate on your dev machine. The web server does it all for you.
No cookie and HTTP caching mess with the HTTP/HTTPS flip-flop
If security/privacy matters, it's the best solution anyway to require SSL for all pages.
Regarding the possible disadvantage: serving a few requests on static resources via SSL is probably almost no overhead, compared to the rest of your application.
I have a 3-node web farm being managed by IIS7 and Application Request Routing. I have a folder hierarchy in my web app that needs to be secured via SSL. What is the best practice for getting ARR to correctly route these SSL requests? I have installed the same certificate on all web farm servers and the server running ARR. I have tried enabling and disabling the SSL Off-loading feature
Thanks,
Matthew
I'm an idiot. I forgot to open SSL through our firewall.