Mailing-List: contact users-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@httpd.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <4B2663B3.1070104@performanceadmin.com>
Date: Mon, 14 Dec 2009 11:11:31 -0500
From: Dan Schaefer <dan@performanceadmin.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.6.0
MIME-Version: 1.0
To: users@httpd.apache.org
References: <4B226A22.9010902@performanceadmin.com>
 <4B25D768.2090800@raad.tartu.ee>
 <680cbe0e0912140028t51fe097ew550cbad909d53fbf@mail.gmail.com>
 <4B2655C2.6010902@newmediagateway.com>
 <4B265726.4030607@performanceadmin.com>
 <4B266151.3020806@newmediagateway.com>
In-Reply-To: <4B266151.3020806@newmediagateway.com>
Content-Type: multipart/alternative;
 boundary="------------040307080404000208080805"
Subject: Re: [users@httpd] Questions about implementing SSL/VirtualHosts

--------------040307080404000208080805
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Justin Pasher wrote:
> Dan Schaefer wrote:
>> So are you suggesting that I need multiple public IPs to implement 
>> this, or just multiple private IPs? Private IPs is not a problem, 
>> however, due to the fact that we have limited public IPS in our 
>> range, it could be a problem when if and when we add new SSL certs. 
>> We would need to re-evaluate our ISP contract before it expires.
>
> You will need a unique public IP address for each SSL site (e.g. FQDN) 
> you are planning on running, unless you have a wildcard cert for 
> multiple subdomains that should all pull the same VirtualHost content. 
> Since SSL encrypts all of the data sent between the server, including 
> the Host: header, there's no way for Apache to know which VirtualHost 
> should handle the request unless it is IP based. SNI[1] is a new 
> extension that allows the Host header to be sent separately, thus 
> eliminating the need for dedicated IP addresses, but it does not have 
> universal browser support (most notably for IE 7.0 only on Vista or 
> higher).
>
> Now, if these sites are being used by the general public, then you 
> don't have to assign unique public IP addresses, assuming the sites 
> are only being accessed through the private IP address on the local 
> network.
>
>
> [1] http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI
>
Does it help to mention that my example.com and www.example.com 
certificates are the exact same cert? My apologies for not mentioning 
this in the beginning. If and when we do add SSL to other subdomains, 
they will be different certs. I *don't* see that happening in the near 
future, however. Will I be able to use the same public IP for both 
example.com and www.example.com?

Dan Schaefer
Web Developer/Systems Analyst
Performance Administration Corp.


--------------040307080404000208080805
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Justin Pasher wrote:
<blockquote cite="mid:4B266151.3020806@newmediagateway.com" type="cite">Dan
Schaefer wrote:
  <br>
  <blockquote type="cite">So are you suggesting that I need multiple
public IPs to implement this, or just multiple private IPs? Private IPs
is not a problem, however, due to the fact that we have limited public
IPS in our range, it could be a problem when if and when we add new SSL
certs. We would need to re-evaluate our ISP contract before it expires.
    <br>
  </blockquote>
  <br>
You will need a unique public IP address for each SSL site (e.g. FQDN)
you are planning on running, unless you have a wildcard cert for
multiple subdomains that should all pull the same VirtualHost content.
Since SSL encrypts all of the data sent between the server, including
the Host: header, there's no way for Apache to know which VirtualHost
should handle the request unless it is IP based. SNI[1] is a new
extension that allows the Host header to be sent separately, thus
eliminating the need for dedicated IP addresses, but it does not have
universal browser support (most notably for IE 7.0 only on Vista or
higher).
  <br>
  <br>
Now, if these sites are being used by the general public, then you
don't have to assign unique public IP addresses, assuming the sites are
only being accessed through the private IP address on the local
network.
  <br>
  <br>
  <br>
[1] <a class="moz-txt-link-freetext" href="http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI">http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI</a>
  <br>
  <br>
</blockquote>
Does it help to mention that my example.com and <a class="moz-txt-link-abbreviated" href="http://www.example.com">www.example.com</a>
certificates are the exact same cert? My apologies for not mentioning
this in the beginning. If and when we do add SSL to other subdomains,
they will be different certs. I <b>don't</b> see that happening in the
near future, however. Will I be able to use the same public IP for both
example.com and <a class="moz-txt-link-abbreviated" href="http://www.example.com">www.example.com</a>?<br>
<pre class="moz-signature" cols="100">Dan Schaefer
Web Developer/Systems Analyst
Performance Administration Corp.</pre>
</body>
</html>

--------------040307080404000208080805--