I have a server hosting multiple web applications using Tomcat 8.0, each one in their virtual host, for example
Virtual Host "a.example.com" points to https://example.com/a
Virtual Host "b.example.com" points to https://example.com/b
My question is that, is there a way I could setup my multiple virtual hosts to use my single SSL certificate? Do i need tomcat SNI support for that?
In order to connect to a.example.com, you'll need a valid certificate for a.example.com. Same for any connection to b.example.com - and as I assume that SNI is ubiquituous by now, I don't know if the answer "yes" would require you to do something different than "no".
In the very special case that you use in your question, you can also work with wildcard certificates for *.example.com - ideally with an alternative name for example.com. It depends on the certification authority that you intend to use if it's available and how much you'll have to pay for it. Of course, if this was only an example, and the actual domain names are more diverse, it's no longer an option.
Just assume you need SNI - there's no problem using it.
Is it possible to run multiple apache sites on the same IP, domain and port (meaning the <VirtualHost> tags are exactly identical and no ServerName is given) while using SSL (not sure whether SSL makes a difference here)?
I would like to separate my web services into files in etc/apache2/sites-available to be able to activate or deactivate them on demand. Basically Apache should just take all files and string them together internally, but leave me the possibility to a2dissite certain parts.
Further clarification:
By "sites", I mean files in the etc/apache2/sites-available directory. "Web services" in this context are certain application like phpMyAdmin or an Etherpad which run on the Apache and whose configuration (e.g. Alias or ProxyPass) I want to write into its own configuration file ("site"),
The short answer is no.
SSL operates at a level between TCP and HTTP. But the virtual host name is sent via HTTP. So how does SSL know which certificate to use for a virtual host?
There is a way to do it - basically start up the HTTP over TCP then switch to SSL after the virtual host name (in the Host header) is sent. However this is complex, error prone and generally considered a bad idea.
Best practice is to have one IP per SSL. One machine can have multitple IP addresses, even a single network port can have mulitple IP addresses.
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 am trying to host 2 sites on a single IP address and they need to be accessed via SSL however the majority of my users use Internet Explorer on Windows XP meaning using multiple SSLs with SNI may prevent them getting access.
I was wondering if I could use a multiple virtual hosts but still use a single SSL certificate and avoid SNI ?
Alternatively how feasible is it for me to install two Apache webserver instances, each its own DocumentRoot and own SSL certificate and for me to simply use the first Apache webserver as an entry point to entertain some requests and to redirect others to the other SSLed Apache instance ?
Could I potentially use the Windows Host file (Windows 2008 Server) to redirect incoming requests to the intended Apache Server instead of using VirtualHosts ?
Apologies if I have confused concepts.
You can try to purchase an X.509 certificate with two domains in it. I don't know what particular CAs do this, but I also don't see why they would refuse. You need to ask their support, though.
Your idea to redirect some requests to another server residing on a different port sounds good as well, though you will have to use two different certificates for different domain names, of course.
Finally if your second domain can be something like additional.mydomain.com , you have greater chance to buy a certificate issued for mydomain.com + www.mydomain.com + additional.mydomain.com (this can be a wildcard certificate or a certificate with additional subdomain names).
What are some good ways to do this? Is it even possible to do cleanly?
Ideally I'd like to use packet headers to decide which server should handle requests. However, if there is an easier/better way let me know.
It's impossible for both servers to listen on the same port at the same IP address: since a single socket can only be opened by a single process, only the first server configured for a certain IP/port combination will successfully bind, and the second one will fail.
You will thus need a workaround to achieve what you want. Easiest is probably to run Apache on your primary IP/port combination, and have it route requests for IIS (which should be configured for a different IP and/or port) to it using mod_rewrite.
Keep in mind that the alternative IP and port IIS runs on should be reachable to the clients connecting to your server: if you only have a single IP address available, you should take care to pick an IIS port that isn't generally blocked by firewalls (8080 might be a good option, or 443, even though you're running regular HTTP and not SSL)
P.S. Also, please note that you do need to modify the IIS default configuration using httpcfg before it will allow other servers to run on port 80 on any IP address on the same server: see Micky McQuade's answer for the procedure to do that...
I found this post which suggested to have two separate IP addresses so that both could listen on port 80.
There was a caveat that you had to make a change in IIS because of socket pooling. Here are the instructions based on the link above:
Extract the httpcfg.exe utility from the support tools area on the Win2003 CD.
Stop all IIS services: net stop http /y
Have IIS listen only on the IP address I'd designated for IIS: httpcfg set iplisten -i 192.168.1.253
Make sure: httpcfg query iplisten (The IPs listed are the only IP addresses that IIS will be listening on and no other.)
Restart IIS Services: net start w3svc
Start the Apache service
For people with only one IP address and multiple sites on one server, you can configure IIS to listen on a port other than 80, e.g 8080 by setting the TCP port in the properties of each of its sites (including the default one).
In Apache, enable mod_proxy and mod_proxy_http, then add a catch-all VirtualHost (after all others) so that requests Apache isn't explicitly handling get "forwarded" on to IIS.
<VirtualHost *:80>
ServerName foo.bar
ServerAlias *
ProxyPreserveHost On
ProxyPass / http://127.0.0.1:8080/
</VirtualHost>
Now you can have Apache serve some sites and IIS serve others, with no visible difference to the user.
Edit: your IIS sites must not include their port number in any URLs within their responses, including headers.
You need at least mod_proxy and mod_proxy_http which both are part of the distribution (yet not everytime built automatically). Then you can look here: http://httpd.apache.org/docs/2.2/mod/mod_proxy.html
Simplest config in a virtualhost context is:
ProxyPass /winapp http://127.0.0.1:8080/somedir/
ProxyPassReverse /winapp http://127.0.0.1:8080/somedir/
(Depending on your webapp, the actual config might become more sophisticated. )
That transparently redirects every request on the path winapp/ to the windows server and transfers the resulting output back to the client.
Attention: Take care of the links in the delivered pages: they aren't rewritten, so you can save yourself lotsa hassle if you generally use relative links in your app, like
<a href=../pics/mypic.jpg">
instead of the usual integration nightmare of every link being absolute:
<a href="http://myinternalhostname/somedir/crappydesign.jpg">
THE LATTER IS BAD ALMOST EVERY SINGLE TIME!
For rewriting links in pages there's mod_proxy_html (not to confuse with mod_proxy_http!) but that's another story and a cruel one as well.
Either two different IP addresses (like recommended) or one web server is reverse-proxying the other (which is listening on a port <>80).
For instance: Apache listens on port 80, IIS on port 8080. Every http request goes to Apache first (of course). You can then decide to forward every request to a particular (named virtual) domain or every request that contains a particular directory (e.g. http://www.example.com/winapp/) to the IIS.
Advantage of this concept is that you have only one server listening to the public instead of two, you are more flexible as with two distinct servers.
Drawbacks: some webapps are crappily designed and a real pain in the ass to integrate into a reverse-proxy infrastructure. A working IIS webapp is dependent on a working Apache, so we have some inter-dependencies.
I see this is quite an old post, but came across this looking for an answer for this problem. After reading some of the answers they seem very long winded, so after about 5 mins I managed to solve the problem very simply as follows:
httpd.conf for Apache leave the listen port as 80 and 'Server Name' as FQDN/IP :80.
Now for IIS go to Administrative Services > IIS Manager > 'Sites' in the Left hand nav drop down > in the right window select the top line (default web site) then bindings on the right.
Now select http > edit and change to 81 and enter your local IP for the server/pc and in domain enter either your FQDN (www.domain.com) or external IP close.
Restart both servers ensure your ports are open on both router and firewall, done.
This sounds long winded but literally took 5 mins of playing about. works perfectly.
System:
Windows 8, IIS 8, Apache 2.2
Installing Windows 10 I had this problem: apache(ipv4) and spooler service(ipv6) listening the same 80 port.
I resolved editing apache httpd.conf file changing the line
Listen 80
to
Listen 127.0.0.1:80
That's not quite true. E.g. for HTTP Windows supports URL based port sharing, allowing multiple processes to use the same IP address and Port.
You will need to use different IP addresses. The server, whether Apache or IIS, grabs the traffic based on the IP and Port, which ever they are bound to listen to. Once it starts listening, then it uses the headers, such as the server name to filter and determine what site is being accessed. You can't do it will simply changing the server name in the request