I have an ASP.Net web application hosted on IIS. The web application (an Umbraco site) is configured to have an HTTP binding in IIS and an SSL certificate is bound to an Application Load Balancer (ALB) in AWS which is used to manage user requests via HTTPS. This means that when a user requests a resource the ALB redirects any HTTP traffic to HTTPS and then forwards the requests to IIS via the port 80 (internal traffic within the VPC).
For most resources this is absolutely fine but there are a handfull of resources (fonts and images) which seem to be requested over HTTP which causes a mixed content warning in the browser. I have tried HTTP -> HTTPS rewrite rules in IIS and outbound rules to rewrite the response but this does not seem to resolve the issue.
Can anyone help?
The solution to the problem was this to run the the web-app locally as HTTPS rather than HTTP and update the load balancer to forward requests to the web-server on port 443 rather than port 80.
To do so
Create a development SSL certificate on IIS. Rather than creating a self-signed certificate I used this project (https://github.com/FiloSottile/mkcert) to do so that the certificate was tusted
In AWS update the target group that the ALB listener used to forward requests to the IIS server on port 443 rather than port 80.
Related
I am new at deploying web applications. I have set up a web server on Digital Ocean that is running on top of NGINX. Besides, I have a front application running on Netlify. The connection between the server and the web is not established (error 400) and I suspect a port problem.
I have double-checked the CORS policy, but my guess is that NGINX listens to port 80 for HTTP request (open), while Netlify automatically creates a SSL certificate which makes my requests go through the HTTPS protocol.
My question is: do I need to do anything else than setting up Nginx on the server side in such a way it listens to port 443 (HTTPS port), or do I need to generate another SSL certificate on the server side?
My intuition is option 1, but I feel lost with all these notions.
its CORS error, your Netlify HTTPS will not allow you to hit insecure HTTP API. You need to enable HTTPS on your droplet on Digital Ocean by providing a Domain Name to your application. Follow the link
I have website and some game server.
I have domain which I connect to Cloudflare.
I want to redirect non http/https traffic to my server IP because when I try to connect to server with domain I can't do this because of Cloudflare proxy.
Maybe it can be done differently?
I use Nginx.
Cloudflare has its own SSL configuration.
There are 4 options for you:
Off disables https completely
Flexible Cloudflare will automatically switch client requests from HTTP to HTTPS but it still points to port 80 on your nginx server, should not configure SSL on nginx in this case.
So the only options for you are Full or Full Strict (more restricted on the cert configured on nginx, must be a valid cert).
With Full you can configure your nginx with a self-signed SSL and let it go. Cloudflare will handle the part between client and its proxy server.
I have a frontend angular application running in a nginx docker container in aws ecs ec2. This is a saas product and other third party domain names will be pointed to this frontend docker container. I have set the default rule to that target group, But I wonder how to set up the ssl for each domain. ALB currently support only 100 listener rules ie in effect each listener will have only 50 rules( considering 80 and 443)
30 rules are already filled by the backend apis.
if I have 150 domains needs to be pointed to this frontend how can I set the ssl? if I set a 301 redirection in the port 80 vhost of nginx like
return 301 https://$host$request_uri
the request will again pass to the application load balancer port 443 and it will take the defaul ssl and may cause ssl error. Is there any chance we can make the nginx https redirection with out going again back port 443 of application load balancer? or any other method? I think the multidomain ssl certificate is an option here so that making it as a defaul ssl on the load balancer.
Do you have access to SSL certs for all these domains? If yes, you can configure them in the nginx container. Use a network load balancer instead of ALB and add a TCP listener on port 443 which will not terminate SSL and redirect traffic to nginx container which will terminate certificate.
You can also dynamically reload nginx configuration to setup certificates dynamically.
AWS load balancers now support SSL redirection so you don't have to do it on your containers.
In addition, your 443 listener can have multiple certificates added to it. So just add all your certs to the 443 listener on your load balancer.
Then in your 443 listener rules, just have a single rule with:
IF: Requests otherwise not routed
THEN:
HTTPS, Port 443
Redirect to 'Original host, path, query'
'301 - permanently moved' as the status
Now all your http requests will be sent back to the user with a redirect back to HTTPS without ever hitting your container or nginx. When they come back as HTTPS, AWS ALB has all the certificates there for it.
If you run up against limits on the load balancer, you may have to 'chunk' them up into 2 or 3 ALBs, but I find this easier to manage especially when cert change time comes around.
I have JAVA REST API Web Server on Tomcat Server which is running on port 8080 in the AWS EC2 instance.
And There is a Classic Load Balancer to manage all traffic for this instance. So before, ELB was on the HTTP and after sometimes, it was routed from HTTPS(443: ELB Port) to HTTP(8080: Instance Port) on the Listeners of the ELB.
And I added inbound rule in the security groups of ELB for HTTPS(443).
Elastic Load Balancer Image
Security Group of Elastic Load Balancer
When I call HTTP request, response is received but when I call HTTPS, it says Could not get any response.
And I added some Web UI to check, that shows for both the HTTP and HTTPS Request but https shows like line-through(HTML type) the https and Not Secure in the URL Address Bar.
check if 443 port is open for the ELB. Go to Security Groups on EC2 console and ensure the ELB security group has port 443 open.
open HTTPS 443 port on EC2 security group
Check if you have a rule set in Ec2 security group which allows inbound traffic on port 443 and port 80 from source ELB security group. If you do not have such rule try adding one and then check again.
I have opened the ports - 80and443 on both the ELB and EC2 sides. Now it is working.
I have multiple sites running on my IIS, now for one of the websites (SiteB) we need to support ssl requests. I have enabled it editing bindings for the website, but the problem is when I selected protocol SSL editing bindings HostName field is disabled, being unable to set hostname to respond to https request, this causes that all sites of my IIS if are requested with https:// loads web site of siteB.
For example my bidings are the next
Site A
IP Port HostName
* 80 www.sitea.com
Site B
IP Port Hostname
* 443 www.siteb.com
* 80 www.siteb.com
If I type https://www.siteb.com in my browser it works correctly, but if I type https://www.sitea.com in the browser, siteb webpage is loaded with the hostname of sitea.
How Can I make that only https://www.siteb.com responds to https requests on my IIS?
I have tried with command appcmd too but It't doesnt work.
appcmd set site /site.name:{sitB} /bindings.[protocol='https',bindingInformation='*:443:*'].bindingInformation:*:443:siteB.com
Thanks for your help.
The Root Problem
This unexpected behavior isn't because of IIS so much as it is because of the web encryption protocols.
The two major web encryption protocols are SSL and TLS. Both of these protocols negotiate a secure connection before passing any request information to the server. This means that, on secure requests, servers don't actually learn the hostname until after the secure connection is made.
An extension to TLS and SSL has been created to address this limitation. It's called SNI (Server Name Identification). The problem is that this extension needs to be supported on both the server and client machines. Currently the client browser support is somewhat spotty. See the SNI article for a browser list.
IIS's Handling Of The Problem
It is because of the above mentioned hostname limitation that IIS doesn't allow you to bind hostnames to HTTPS bindings. There is no way for IIS to route HTTPS requests to a particular hostname since it doesn't know the requested hostname when it first begins to negotiate the connection.
Once IIS has negotiated a secure connection with a client and learns that their requested hostname is for a site other than the one with the HTTPS binding (e.g. a request for https://sitea.com) IIS can either return a failure code or try to fail gracefully. IIS chooses the latter and tries to fail gracefully by serving up the site with the HTTPS binding even though the user is requesting a different site.
Solutions/Workarounds
Create a rewrite rule to redirect all HTTPS requests for nonsecure websites to HTTP.
Upgrade to IIS 8 to use the SNI extension. Then ask visitors to upgrade to browsers that suport SNI.
Have your secure site return an error message when it receives a request for a different domain.
Bind by IP address instead of hostname since IIS can route HTTPS requests by IP address
References
Most of my information came from the Wikipedia article on SNI
We run webservers with multiple sites requiring SSL with no problem.
If I understand your problem correctly - you'll need to set up a binding instead of a host name - which won't work. So, for each SSL-enabled site we host, we require a distinct external IP address. Then, enter that IP address as the binding when setting up the site in IIS.