[olug] SSL for Multiple Apache Named VirtualHosts on a single IP?

Rob Townley rob.townley at gmail.com
Sat Mar 6 02:32:40 UTC 2010


On Thu, Mar 4, 2010 at 10:00 PM, Phil Brutsche <phil at brutsche.us> wrote:
> Your frustration has nothing to do with SSL or TLS but with traditional
> HTTPS implementations.
>
> Traditionally HTTPS is SSL-on-connect - you connect to port 443 and
> immediately begin negotiating your SSL or TLS session. *Then* you begin
> your HTTP protocol chatter, which includes the Host header.
>
> The *only* way to do what you want with traditional HTTPS is with
> wildcard certificates.
>
> The modern way to do SSL/TLS is to connect to the plain-text port,
> exchange capabilities information to verify the server is capable of
> upgrading to an encrypting session, and issuing the command to do so.
> The command is typically STARTTLS, as implemented by numerous SMTP and
> IMAP daemons.
>
> That is not the only way to do it, however, and that is not the method
> HTTP daemons and web browsers have chosen.
>
> The industry has been coalescing around an extension to the TLS protocol
> that exchanges server name information as part of the TLS negotiation.
> The extension is defined in RFCs 4366 and 4346. It is referred to as the
> TLS SNI extension.
>
> More details: http://en.wikipedia.org/wiki/Server_Name_Indication
>
> Rob Townley wrote:
>> OS = CentOS 5.4
>>
>> Apache 2 by itself is  not  capable of supporting more than one SSL
>> enabled name based virtual host on the same numeric IP address.  So
>> each VirtualHost effectively needs its own IP.  Are Apache's
>> limitations true even of wildcard SSL certificates?
>> http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#vhosts
>> http://askcolddrink.blogspot.com/2007/03/apache-httpd-virtual-hosts-and-ssl.html
>>
>> That is frustrating because the SSL Certificate itself is not tied to
>> an IP address, but the SSL protocol seems to force the binding to a
>> single IP name.  Security has got to be easier than this this by now.
>> i compiled and wrote OpenSSL windows services 10 years ago, so i am
>> rusty.   But i do remember TLS promised something better, but the
>> browsers didn't support it.   These are internal private only web
>> servers, so i can add more numeric IP addresses, but i would much
>> rather not have that overhead.
>>
>> I.]  There has got to be an easier ready-to-go framework running on
>> top of Apache to facilitate a way to handle multiple name based SSL
>> VirtualHosts on the same IP?  Hibernate? Spring? Joomla?  Drupal?
>> Which one would work best for forcing https on the login pages for
>> various sysadmin pages such as FreeGhost, drbl, ocsinventory-ng, rt,
>> phpMyAdmin each with their own subdomain name?
>>
>> II.]  If all the VirtualHosts are in the same domain name and that
>> domain name has a wildcard SSL certificate, is there some way around
>> Apache's limitations?
>>
>>   A.) Self generated *.DomainName.com WildCard SSL certificate.
>>   B.) VirtualHosts all within that same *.DomainName.com wildcard.
>>   C.) ServerNameAlias  with all the different server names in a single
>> VirtualHost entry.
>>   D.) Perl / Python / PHP script that reads the client's host
>> directive and then rewrites it to somewhere else maybe using
>> VirtualDocumentRoot.
>>
>>
>>
>> III.] Something involving reverse proxy but that is overkill.
>
> --
>
> Phil Brutsche
> phil at brutsche.us
>


However, the /var/log/httpd/error_log entry  "[Fri Mar 05 20:22:03
2010] [info] Init: Initializing (virtual) servers for SSL"  indicates
SNI  may work.  i have openssl 0.9.8e but some docs say openssl 0.9.8f
is needed to do Server Name Indication.  Along with compile time
options that i am not sure i see with httpd -V.   i am glad SNI is an
option, but i decided for now WildCard ssl would be quicker to try
out.

Thanks for the confirmation that wildcard certs would work without
multiple IP addresses because i didn't want to spend a great deal time
on it unless there was a probability of success.   It seems to work,
but i more testing is called for.
Putting wildcard cert and key pointers into ssl.conf was less than 5 minutes.
Remembering my TinyCA2 password, 2 months and a couple pints of smithwicks.



More information about the OLUG mailing list