Subject: RE: Virtual hosts and ssl.

From: David Buerer <[email-masked]>
Date: Fri, 1 Mar 2002 08:05:30 -0800

Andrew, 

You raise many interesting points in your letter.  I've interlaced my
comments below:

>It seems to me that every hosted DN would need to have its own CERT.  Sure,
>the server could have just one CERT, with all of your DNS users sharing it,
>but then the identity being confirmed would be that of the ISP.  What good
>would that do for me as a purchaser, to access the Encrypted Key of the ISP
>if the company with whom I am transacting business is simply one of their
>hosted Domain Names?

You're right with only one exception.  Certificates are issue for a single
domain name.  Period.  Not an IP address, not a server, but only one FQDN.
Thwate does offer one type of certificate, the "supercert" which is valid
for a parent domain and all sub-domains underneath, but it's not quite
compatible across all browsers.

>If there is a way around having to purchase one CERT per Domain Name, I
>would like to discover it. However, if I am understanding this correctly,

Ditto here.  I think it's ridiculous that a certificate will not
automatically apply to all sub-domains. When you've got multiple servers, or
multiple hosts which are used on a very large site to manage the sub-domains
and you have to purchase a yearly certificate subscription for each, it's
not only expensive, but a pain, and I'm not sure what the justification is
for this.  If the root domains are secure, why shouldn't the sub domains be
as well????  Maybe the certifying authorities need the money.  Who knows.

>multiple domains can share one IP (which is how I host most domains), but I
>never did understand the use of Name-Based VH's.
>In what context are Name-Based VH's of value?  From what Jeff states,
>obviously not on SSL.

Name based virtual hosts are critical anytime you've got redundant servers.
For example, consider two servers www1.x.y and www2.x.y. These two server
are used for redundancy/fail-over and load balancing.  With the advent of
name based virtual hosts, both servers can use identical configuration
files.  This reduces the administrative time since the config files are the
same.  It also give you the ability to setup a continuous replication of the
drives to that all changes on one machine automatically transfer to the
other machines in the cluster. This is a really good thing.  However, since
cert's only apply to one domain, you must purchase one cert for each
domain/sub-domain on each computer.  So, if you've got two redundant servers
hosting one site with four sub-domains each, you just had to purchase (8)
certificates yearly.  Talk about $$$$.

So there's my two cents.  As I see it, there are 3 reasons you would use
this type of security, 1.) Authenticate the connection, 2.) Secure/Encrypt
the data, 3.) Authenticate the individual you're doing business with. Items
#1 and #2 in my opinion are the only things you as a
consumer/client/customer should depend on SSL for.  Given that, there is no
reason that all certificates could not be provided domain wide.  As to item
#3?  Well, I kind of take the stand that it's the duty of the client to
verify the integrity of the person you're doing business with--not a false
reliance on SSL to indicate "this is someone I should give my money to." 

How do you get around this problem?  To my knowledge there isn't any
reliable way.  In the interim,  I have one domain on one IP on one server
that takes care of all my SSL needs for all of the sub-domains. However,
this is only going to work for so long. I don't get the redundancy I need
and administratively it's not very efficient.  Oh well.  If anyone has come
up with any other great ideas, I'd love to hear them.

>Andrew L.
>The ACL Group, Inc.

David Buerer
TecnoGenesis, LLC

______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl)                   www.modssl.org
User Support Mailing List                      [email-masked]
Automated List Manager                            [email-masked]