SSL certificates on Apache Virtual Servers

Cross posted to alt.apache.config and comp.os.linux.networking

Hi,

I want to create a number of Apache Virtual Servers for different customers.
I have a requirement to provide a Secure Sockets Layer using HTTPS.

http://www.instantssl.com/ssl-certif...te-apache.html

has a line saying:

<snip>
When I access my secure site, a certificate for another site is displayed
This problem occurs if you assign the same IP address to each host in your
config file. SSL does not support name based virtual hosting (host headers
are encrypted in SSL), so only the first certificate listed in your config
file will be used.
</snip>

So, as these are commercial customers, how can I configure the Virtual
Servers/Certificates so that they authenticate properly. We were planning to
use a single IP address for all servers, behind a content switch, but now I
am unsure exactly what configuration options I have available.

Anyone suggest a solution or have I misunderstood the problem.

Thanks


Martyn

--
===========================
Martyn Kinder G0CZD

Open-Xchange 0.8.0.5

As far as I know this is just not possible. For a detailed explanation
see:

http://httpd.apache.org/docs/2.0/ssl...aq.html#vhosts

Essentially the problem is that https handshake occurs before your
server can get to the host name in the request. While it can direct a
client to the right virtual host, the server certificate will allready
have been presented to the client.

(E-Mail Removed) wrote:
> As far as I know this is just not possible. For a detailed explanation
> see:

Thanks

I was starting to suspect that. :-(

Martyn

--
===========================
Martyn Kinder G0CZD

Open-Xchange 0.8b5

http://www.czd.org.uk

(E-Mail Removed) wrote:

> As far as I know this is just not possible. For a detailed explanation
> see:
>
> http://httpd.apache.org/docs/2.0/ssl...aq.html#vhosts
>
> Essentially the problem is that https handshake occurs before your
> server can get to the host name in the request. While it can direct a
> client to the right virtual host, the server certificate will allready
> have been presented to the client.

However, you can do it for subdomains with a wildcard SSL cert so that
*.exmaple.com all use the same cert without warnings (AIUI). The only
thing you'd have to do is get the one wildcard cert and set up each
client with a subdomain instead... May not be what you are after, but
gives you another option to look into anyway.

--
Justin Koivisto, ZCE - (E-Mail Removed)
http://koivi.com

"KM" <(E-Mail Removed)0sp4m> wrote in message
news:(E-Mail Removed)...

> So, as these are commercial customers, how can I configure the Virtual
> Servers/Certificates so that they authenticate properly. We were planning
> to use a single IP address for all servers, behind a content switch, but
> now I am unsure exactly what configuration options I have available.

You really should not be hosting commercial customers on a shared IP
address. You should by now have discovered at least one reason why that
doesn't make very much sense.

DS

>You really should not be hosting commercial customers on a shared IP address. You should by now have discovered at least one reason
>why that doesn't make very much sense.

and why not host on a shared ip address as isp's do this all the time to reserve ip addresses for other services !!!


"David Schwartz" <(E-Mail Removed)> wrote in message news:dht76i$hr4$(E-Mail Removed)...
>
> "KM" <(E-Mail Removed)0sp4m> wrote in message news:(E-Mail Removed)...
>
>> So, as these are commercial customers, how can I configure the Virtual Servers/Certificates so that they authenticate properly.
>> We were planning to use a single IP address for all servers, behind a content switch, but now I am unsure exactly what
>> configuration options I have available.
>
> You really should not be hosting commercial customers on a shared IP address. You should by now have discovered at least one
> reason why that doesn't make very much sense.
>
> DS
>
>

"Newsgroup Poster" <(E-Mail Removed)> wrote in message
news:dhtlnk$5qr$1$(E-Mail Removed)...

> >You really should not be hosting commercial customers on a shared IP
> >address. You >> should by now have discovered at least one reason why
> >that doesn't make very much sense.

> and why not host on a shared ip address as isp's do this all the time to
> reserve ip
> addresses for other services !!!

I think the present case serves as a very good demonstration of what
some of the problems are. There are lots more. For example:

1) Not all protocols (for example SSL) can support name-based hosting.
What do you do when the customer decides they need an FTP site as well?

2) Reverse address resolution will not give any information about the
host the user tried to reach. This can cause problems with logfiles,
firewalls, and other issues. If a program legitimately tries to access
'www.trustedsite.com' but the firewall/router log or alter box shows a
connection attempt to 'www.siteineverheardof.com', how do I know the
connection should be allowed? If the web site, for example, is used as a
place for compromised machines to post their IP addresses, network logs
won't show the appropriate person to contact.

3) Even for HTTP, name-based hosting is a hack. Not all browsers even
support name-based hosting. What do you do if you receive a request that has
no headers? (Which is perfectly legal.)

4) It creates cross-site security issues with Java. (Java's security
model assumes that the IP of the server that sent the Java client can be
trusted. If that IP is not under common administration, that assumption
becomes false.)

5) It just doesn't look professional. Sometimes it can result in the
hosting company being contacted when the customer should be contacted (due
to reverse DNS). This forces the hosting company to figure out the right
customer and refer a contact to them. This makes your customer look
amateurish.

6) Error messages can't always be appropriate. Server administration
identification can't always be correct. Log files can't always be correct.
(For example, suppose some error causes a connection to break before the
Host header is sent or received. What customer is having the issue?)

7) If DNS has problems, troubleshooting is much harder. How can you tell
if your web page is working if DNS is not working?

These are just the most obvious reasons. There are lots of subtle and
more bizarre ones that you run into. The plus is what exactly? IPs are not
that scarce.

DS