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.
Related
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).
I have a question, I fear the answer.
I have:
a top level domain name (free from Tokelau, a territory of New Zealand, .tk, where else?),
a free 2 year ssl certificate from startSSL.com,
a free hosting package.
Now I jumped through every hoop startSSL wanted (admittedly wasn't too difficult), to get me my 2 year ssl certificate, and now I fear I have encountered a final barrier to success that might still stall my plans. I dreamt of a corner certificate stating "Secured by startSSL". I got the code snippet and everythings, and have pasted it into my website.
Problem. my host is not so keen on a free package to allow me to ssl.
As far as I know you need access to some config files to allow this to happen?
or can you just like with .htaccess and .htpassword files do the setting on your webhost?
Also you need a static IP. Are there any workarounds?
Or am I dreaming? Anyone with advice?
SSL Requires some files and configuration changes, pointing to the files.
Also, the static IP is required because with an encrypted request, there's no way to know to what host the request is intended without decryption. The use of a static IP address gives that request a destination.
To clarify: when using virtual hosts, multiple hosts will share the same IP address, so when a request comes in, the first two lines are:
GET /path/to/resource HTTP/1.1
Host: www.example.com
Apache (or any web server), looks at the 'Host' field to determine how to route the request. If the request is encrypted, there's no way to determine how to route the request, and you need to know what certificate to use in order to decrypt it.
Forget it. If your host doesn't have SSL configured, you have no chance to add it without their help
There are two problems with your proposed set-up.
Free hosts generally don't provide a control panel interface to allow installation of SSL Certificates (at least I've never seen it) as this requires either their help on the back-end or VPS / Dedicated Server access from the front-end.
Static IP address is a must for SSL certificate installation.
From webserver perspective, SSL cert is about a port and an IP address, even when being used with Name-based virtual hosts.
SSL is about the IP the matching the cert and domain in the URL/request(to verify the cert).
You would have to give a second SSL cert different port or different IP address on the webserver.
Alternatively, you can also get multi-domain and wildcard certs that allow different hostnames or domains to match the cert with different client request URLs, but the cert is still the only thing on that port/IP of the webserver.
Just my $.02
How would I self assign a SSL Cert on Apache (XAMPP) on a Windows 2003 server? I have researched and the farest I got was a broken SSL Cert with "Common name" problem.
Post your guide or links here,
Thanks.
If you are in development and using localhost, the common name of your ssl certificate should be localhost. If you are using a machine that uses dns (or the hosts file) you should use that host name as the certificate common name (cn). E.g. if you are using www.mydomain.com you should create a certificate with that name. You can also create a certificate with the name *.mydomain.com that you should be able to use on all subdomains of mydomain.com. You may want to read this tuturial on the subject.
We have a site www.name1.domain.com for which we successfully created and implemented an SSL cert. We then added another site, www.name2.domain.com, and are seeing some strange behaviour in IE7 and IE8 (surprise!).
Basically, IE7,8 reports a mismatch of host name when we go to https://www.name2.domain.com/ . When I add and view this cert in IE for this domain, the host name is incorrect, but belongs to the older host name, i.e., www.name1.domain.com.
Firefox doesn't have this issue, and picks up correct host name www.name2.domain.com for the second site without issue.
Any ideas why IE is misbehaving (apart for the sassy ones (-: ) ?
Your problem is that Internet Explorer on Windows XP (and probably other software as well) is not SNI capable.
I've just ran into the same problem - basically Firefox and Chrome are ok and get the correct certificate, but Internet Explorer does not. Then I've looked it up a bit and saw this on Wikipedia, among other things:
Browsers with support for TLS server name indication [7] Internet
Explorer 7 or later, on Windows Vista or higher. Does not work on
Windows XP, even Internet Explorer 8.
So, your apache/openSSL combo is SNI capable and can do this, but Windows XP is not.
My solution is that I'm putting the primary subdomain first in the VirtualHost configuration, and the secondary less. At least there is less explanation to clients on why this pops up.
I don't know if it would work for you though.
Firefox supports running SSL over the same port,443 (using the same IP) to two virtual hosts (in Apache), but IE7 does not.
http://www.eggheadcafe.com/software/aspnet/36069240/sni-support.aspx
====
http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#vhosts2
Why is it not possible to use Name-Based Virtual Hosting to identify different SSL virtual hosts?
Name-Based Virtual Hosting is a very popular method of identifying different virtual hosts. It allows you to use the same IP address and the same port number for many different sites. When people move on to SSL, it seems natural to assume that the same method can be used to have lots of different SSL virtual hosts on the same server.
It comes as rather a shock to learn that it is impossible.
The reason is that the SSL protocol is a separate layer which encapsulates the HTTP protocol. So the SSL session is a separate transaction, that takes place before the HTTP session has begun. The server receives an SSL request on IP address X and port Y (usually 443). Since the SSL request does not contain any Host: field, the server has no way to decide which SSL virtual host to use. Usually, it will just use the first one it finds, which matches the port and IP address specified.
You can, of course, use Name-Based Virtual Hosting to identify many non-SSL virtual hosts (all on port 80, for example) and then have a single SSL virtual host (on port 443). But if you do this, you must make sure to put the non-SSL port number on the NameVirtualHost directive, e.g.
NameVirtualHost 192.168.1.1:80
Other workaround solutions include:
Using separate IP addresses for different SSL hosts. Using different port numbers for different SSL hosts.