I have installed an SSL on ELB. I have one EC2 instance in the ELB and can access the website via the SSL fine (IIS Windows 2008 server).
The confusion is when I am in NON HTTPS and I perform a redirect in my app to the HTTPS area, I get an error.
Doing some digging in the listeners area, I can see Port 443 on the ELB forwards to port 80 on the instances which makes sense, but then how do I handle this scenario?
For now, I have 'hacked' it by adding a self signed cert on my instance and then forwarding 443 from ELB to 443 on the instance, but this kind of defies the point?!
Any advice on how this should be structured would be great!
You have both port 80 and 443 on you load balancer forwarding to port 80 on your instance, so you need to figure out how to tell them apart.
The ELB sets a header value so you can tell these two types of requests apart.
Take a look at http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/TerminologyandKeyConcepts.html#x-forwarded-headers but the value you want to check is X-Forwarded-Proto - this should have http or https, and obviously if it's http you would then redirect to https.
Related
Here we are using haproxy for the redirection of HTTP to https, at backend we use the gateway. here gateway having already ssl certificate we redirected to it directly through HAProxy.
We have 2 URL one hit on port 80 and 2nd hit on port 8080 what are the possible conditions required for that have tried all possibilities. without using SSL it's working but regarding to the SSL it can't work it only work on 443 and its only applicable to the port 80 not getting assign to others.
I have a website setup, if I load the website with http://www.url.com:443 it works as expected, but if I load https://www.url.com I get a "ERR_CONNECTION_CLOSED" error on Chrome.
I have setup iptables to load port 3000 through both port 80 and 443.
Server is running centos, there is no ssl certificate setup at this stage
You configured the server to listen on port 443 but didn't configure it for SSL traffic. In other words, you merely changed the port from 80 to 443, so it is serving HTTP on port 443.
You say there are no SSL certificates set up. That's the problem. You need to set up certificates (even if only self-signed ones) for HTTPS to work at all. It's the key and certificates from this setup process that tell the server how to encrypt the HTTPS data, and how to identify itself.
This page will help you to set things up properly: https://wiki.centos.org/HowTos/Https
There are many places you can look for advice on creating keys and certs, but the easiest and least expensive options are StartSSL and LetsEncrypt. Both will do this for you at no cost.
https://letsencrypt.org/
https://www.startssl.com/
I'm trying to figure out the best way to manage HTTPS for an EB docker application.
At the moment I'm using the following approach.
ELB accepts HTTPS connections on 443, and forwards to HTTP port 80 on the instance.
ELB accepts HTTP connections on 80, and forwards to HTTP port 8080 on the instance.
Instance accepts HTTP connections on port 80 and forwards to docker app.
Instance accepts HTTP connections on port 8080 and redirects them to HTTPS.
This all works reasonably well. It means the docker app doesn't have to worry about redirects at all. It just listens on port 80, and does it's thing. The ELB and docker host do the rest.
My only concern with this setup, is the docker app doesn't know that it's running secure. If within my application I check for this, it'll fail.
I want to completely separate my docker app from domain names, and SSL certificates that may change, so I would prefer to continue terminating the original HTTPS connection at the ELB. I'm wondering if there is some way I can get the docker host (or ELB) to forward (re-encrypt) request in HTTPS protocol, but using a self-signed certificate, so I can keep it completely generic.
Just to be clear, this would only be between the ELB and/or docker host, and my docker app, not to the browser.
If I create a non-expiring self-signed certificate, and then register this with the web-server in the docker app (currently using Apache2, but could potentially use nginx), and then simply tell the ELB, or docker host to forward requests as HTTPS, will this work? Or would it fall over at some point because the certificate isn't trusted?
Or is there some way to be able to terminate a HTTPS connection at the docker app web-server without actually needing to pre-generate a certificate (I'm guessing no on this, as presumably it'd need to generate a certificate on the fly or something).
Is there a recommended best practice way to do this kind of thing?
A common solution when you have a load balancer terminating client connections and forwarding to backend is for the load balancer to add headers onto the backend requests to fill in any information stripped by having the load balancer there.
ELB has a page on this and uses the following headers:
X-Forwarded-For - The client IP
X-Forwarded-Proto - The scheme/protocol
X-Forwarded-Port - The incoming port.
You would generally not allow these headers directly from the client, unless they were a trusted client. I assume ELB takes care of that for you.
I've used both Apache and nginx as a reverse proxy performing HTTPS termination (listening on port 443) and forwarding the unencrypted HTTP traffic to Tomcat on port 8080 before.
However, what I need to do now is do the opposite. I have some client applications running on localhost that are (for simplicity) just talking plain HTTP. I want to be able to tell these client apps to use a forward proxy (on localhost) that will convert them to HTTPS and use a client-side certificate for the communication to the origin. Ie, the client will think it is communicating plain HTTP on port 80, but the traffic will actually leave the host as HTTPS on port 443.
Does anyone know how to configure mod_proxy to do this (or even if it is possible)?
At a further stage, I may need to configure the proxy to use different client certificates based on headers set by the client and also have mod_proxy use RFC 5077 (quick session resumption).
It doesn't have to be Apache (so if nginx or squid can do the function I'm happy with that) as long as it's not a resource hog. We already have Apache running as a reverse proxy anyway so it would be handy if Apache can do it.
When having multiple domain names point to the same server. But you only have a certificate for one of these domains, is it possible to block the other domains in Apache. But only when HTTPS is used not when HTTP is used.
I tried using a NameVirtualHost setup for 443 port. But when the domain is not found Apache simply defaults to the first virtual host. I would like it to refuse the connection. In this way when connecting directly through HTTPS on one of the not supported domains the connection is refused rather then having the browser display warning screen because of a wrong identity.
Any thoughts?
Not possible.
This is a chicken and egg problem - to verify an https connection the browser connects and tries to validate the certificate/common name and the given URL. The first handshake / connection to port 443 has to be encrypted.
The only way to handle this problem would be to setup dedicated IPs for all domains - or for at least the domain using HTTPS.
It's far from ideal, but another option would be to use a non-standard for your HTTPS site and not have the server listening on port 443.