I am in the process of migrating a webapp from one server to another, and the IP address of the servers are different. I need to change the A record for the domain to the new server. To make sure the traffic to the old server lands up in the new server I need to setup reverse proxy in the old server which will redirect all traffic to new server.
I have several domains in the same server with different SSL certificates. The client will have a SSL connection the old apache server and the new server will accept connections through SSL only. So I need to setup reverse proxy with SSL connection. Is this possible in apache ? How do I achieve this? I am also worried about slowness due to two SSL connection setup times.
Yes, it is perfectly possible using mod_proxy and mod_ssl. See :
https://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslproxyengine
As mentioned by Remi, it is possible and to add, you do not have to worry about 2 SSL connections since I am assuming that the reverse proxy connection would have keep alive switched on and therefore the SSL connection setup between the two servers would only be carried out intermittently.
So remember to setup keep-alive. Any server worth its salt would support that and Apache does too.
In the old server I would perform browser redirection "301 moved permanently" to the other IP/hostname (probably on the app root too, just to annoy them enough to change their bookmark and stop using ip addresses in favor of hostnames) . Light and effective.
Related
In the documentation for icecast 2.4.2 I see the following about ssl.
ssl If set to 1 will enable HTTPS on this listen-socket. Icecast must
have been compiled against openSSL to be able to do so.
However this wording is unclear to me whether or not the ssl is forced for this port or not? I am wondering this because we are running into an issue where safari is forcing ssl redirect and we want to keep the server listening on both ssl and non-ssl on the same port ( if thats possible )
Another thing is that it says it must be compiled against openSSL but we are installing it from apt in xenial. Does this mean its default to ssl?
Thanks~!
However this wording is unclear to me whether or not the ssl is forced for this port or not?
On that particular socket, it is. A server bound to that socket cannot support HTTPS and non-HTTPS at the same time. Usually, you'll use port 80 for HTTP and port 443 for HTTPS.
Note that you can have multiple sockets bound to Icecast, simply by putting in multiple <listen-socket> sections. It's common to serve both HTTP and HTTPS this way.
I am wondering this because we are running into an issue where safari is forcing ssl redirect
Your server configuration is irrelevant here. Icecast will not redirect HTTP requests to HTTPS. It's possible that you hit the stream on HTTPS once and that Safari cached this. It's also possible that you turned on HSTS or something for your domain. You would have to debug this with a tool like Fiddler.
and we want to keep the server listening on both ssl and non-ssl on the same port
You say "keep the server listening"... that's not possible. If it appears you're set up this way today, that's not accurate.
In a sense it does. Icecast if you are using it as its own server will not resolve the enabled ssl port unless its https://.
You also cannot use the same port for both ssl and non-ssl.
Finally the xenial ubuntu package also is not compiled for ssl.
Guess this is the only post ever where I start with: "My SSL connection works but I don't know why".
I have a setup where the domain name and wildcard certificate lie on server A, and I want to use a subdomain of that domain to proxy requests to server B on another machine somewhere on the internet. Server B is currently only reachable via an IP, so I actually did not expect this to work, because SSL-certificates are based on domain names.
My setup is as follows (example):
Server A domain: www.production.io
Server A Subdomain: cus1.production.io
Server B IP: 65.23.523.12
Apache config for http of cus1.production.io:
RequestHeader set X-Forwarded-Proto "https"
ProxyPreserveHost On
Redirect / https://cus1.production.io/
Apache config for https of cus1.production.io:
ProxyPass / http://65.23.523.12/
ProxyPassReverse / http://65.23.523.12/
Calling cus1.production.io shows the application on 65.23.523.12 but with a secured connection (green lock) in the browser though the webserver on Server B does not offer https connections nor does it provide an SSL certificate.
Although the connection between a client and the "proxying" Server A is secure, the data transferred to the actual application is not. So this is actually a fraud.
Question: How do I make sure a secure connection will be applied between Server A and Server B?
It's not really "fraud", it's just that the SSL/TLS connection is ensured between the browser and Server A. The browser has nothing to do with Server B: Server A is the client to Server B.
If you can, set up SSL/TLS on Server B. Even if it's only accessible with an IP address, you could create your internal CA or a self-signed certificate. (That certificate should have this IP address in a SAN entry of IP address type.)
Then, you can use mod_ssl's SSLProxy* options to configure how Apache Httpd (on Server A) behaves as a client to server B (i.e. when it's a reverse proxy).
Typically, you'll need to set SSLProxyCACertificateFile (to point to your internal CA cert or that self-signed cert) and use SSLProxyCheckPeerName.
In short, it's up to you to make sure.
What you've just described is a common way of configuring SSL setups, where you have one set of servers that handle the secure connection to the browser, then they proxy the requests to another server, often just with http. This is known as ssl termination.
Usually this connection is done within a secure network, the servers hosting the certificates can be accessed from the internet, but the servers they forward to are not, so they don't proxy back across the internet. However, there is nothing in theory to prevent this if your servers aren't configured properly.
If I got a signed certificate from letsencrypt.org and baked it into my nginx web server, does that mean I still need to configure express.js to use https?
As in nginx serves me a secure webpage, and I see the https lock on the top left, but do I need to do any extra configuration with express at all??
No node/express does not need to handle ssl - you can have a separate service for node/express and have nginx act as a reverse proxy and do ssl offloading.
Under this configuration, browsers will first hit your nginx web server over HTTPS, nginx will handle the ssl decryption and forward the decrypted HTTP request to your node process.
Your node process doesn't have to know HTTPS is happening at all.
Digital Ocean really has the best docs for setting this up on linux with systemd.
The first link is a clear tutorial on setting up a an nginx reverse proxy to node
The second link shows configuring SSL in nginx w/ a simple reverse proxy (in this specific example - its not a node server on the receiving end but the concepts are the same) to accomplish the SSL termination
I have tomcat installed and running on an ubuntu 12.04 LTS system utilizing port 443 for https requests (GeoTrust certificate installed).
On the same machine, apache2 responds to requests on port 80.
Now I was given to task to secure the webapps (php) running on apache2 with SSL as well, but with a different server certificate.
Is this possible at all? - My assumption would be "no", because I cannot have two servers listening on the same port, but I'm not too sure and haven't found any helpful information about this so far.
Any help would be highly appreciated..
These days, you'll still have difficulty serving more than one certificate on a single interface/port combination (e.g. 0.0.0.0:443). IF you want to use two separate ports for HTTPS, it's no problem. If you want to bind to different interfaces (e.g. 1.2.3.4:443 and 4.3.2.1:443) it's no problem. If you want them both on the same interface/port, you'll have to rely on Server Name Indication which may or may not be supported by your web server version and/or client.
If you want different certificates, you probably want different hostnames, too, so maybe you can get a second interface configured on the machine. Note that you don't need to have multiple NICs on the machine just to enable a different interface: your OS should be able to create another interface with a different IP address and still share the NIC. Then you just set DNS to point each hostname to a different IP address and make sure you bind each SSL VirtualHost to the proper IP address (instead of using 0.0.0.0 or * for the hostname).
Honestly, SNI is the easiest thing to do: just use VirtualHosts with SSL enabled (with different certs) in each one the way you'd "expect" it to work and see if the server starts up without complaint. If so, you'll need to test your clients to see if it's going to work for your audience. For the SNI scenario, I am assuming that Apache httpd would handle all of the SSL traffic and that you'd use something like mod_proxy_* or mod_jk to proxy to Tomcat.
For the split-IP scenarios, you can do whatever you want: terminate SSL within Tomcat or use httpd for everything and proxy for dynamic content to Tomcat.
I have made reverse connection to one of web servers on which is SSL applied and the the content is in dir (http://webserver.com/directory) ,so i had to use rewrite rule and that works well.
The thing is that nginx can't pass SSL from backend webserver and i get error on silverlight application..
Could someone advise me on what to do ? Config is very basic as only rewrite is added additionally.
Looking forward for suggestions,ideas,answers.
Best regards.
Edit: pastebin.com/SnyHaUL4
As far as i know, you could say that "it's not a bug, it's a feature", one of the features of SSL that it prevents Man in the middle attacks, if you want to use SSL then nginx it self should have an SSL key and allow https connection, otherwise the user will see the well known yellow warning page about untrusted SSL,
If you implement the SSL for nginx, then the connection would be like this
client -> nginx ssl -> nginx -> server ssl -> server
The connection will be encrypted and decrypted twice on the way to the server, the client wont see the server SSL and will only see the nginx SSL.
If you don't have or don't want to use SSL on your nginx, then you need to make the connection to it unsecured, then the warning won't appear and every thing would work fine.