httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Rogers <dan...@phasevelocity.org>
Subject Re: SSL enabled name virtual hosts
Date Mon, 06 Mar 2006 19:05:00 GMT
On Mon, 2006-03-06 at 13:38 -0500, Eric Covener wrote:
> On 3/6/06, Daniel Rogers <daniel@phasevelocity.org> wrote:
> 
> > My SSL virtual hosts are, effectively, Name based, not port based (there
> > are only two ports involved 443, and 444 for unlimited virutal hosts).
> > All ssl virtual hosts are on port 444, and their name is used to
> > distinguish them.
> 
> So you're unable to  set things like client authentication, CRL
> checking, or restrictive ciphers at a per-vhost level?  It's unclear
> to me  whether the specific vhosts are HTTP or HTTPS, but either way
> it's not the browser talking to them, right?

So, something I want to point out here.  What I did was a hack.  If it
was implemented from within Apache, I do not believe the extra port
number would be necessary.

First, how I made it work:
That is correct, you are unable to set things like client
authentication, CRL checking or restrictive ciphers on a per-vhost
level.  It is, however, better than nothing.

The specific vhosts don't know they are HTTPS.  and no, the browser is
not talking directly to them.

Second, how I would like it to work (from within apache):
That is correct, you are unable to set things like client
authentication, CRL checking or restritive ciphers on a per-vhost level.
It is, however, better than nothing.  I suggested before that the syntax
in the config file could be:
<SSLNameVirtualHost *:443>
/all ssl options here/
</SSLNameVirtualHost>
Where all the ssl options for all name based virtual hosts would be
kept.
The specific vhosts, while unable to specify ssl options, would know
based on the environment presented by apache, that they are talking ssl
on the normal port.  The vhost would be talking directly to the browser
and so access controls from within apache would work.

> 
> Don't you get this same "solution" with 1 RewriteRule (proxied, not
> redirected) and a certificate crafted the way you describe?

Wow.  I think that might be tremendously easier.  I had to read a lot of
documentation.  I found AliasMatch and made it work with that.  I should
have kept reading, apparently.

> 
> > I'll answer these two points together.  subjectAltName doesn't have to
> > allow an "all purpose" certificate.  It can be on a single host, or an
> > enumerated set of hosts.
> 
> How do you add a new host?  How do you revoke a certificate or know
> where to do CRL checking for an organization if it's all common?

Indeed the certificate management gets somewhat harder, it seems.
You add or remove a host be revoking the old cert and issuing a new one,
with the updated subjectAltName.  I am not sure I understand your second
part.  You can still revoke a certificate, just as before, that is no
different.  The CRL is managed by the CA, is it not?  If you are
revoking multihost certs with your CA, in order to add new hosts, your
CA is still managing it.  I am failing to see how the situation is
different, except you are likely to be revoking and reissuing the
certificate more often.  In other words, I was under the impression that
the CRL was central to the CA anyway.  No matter how the certs are
organized, the CRL for an oranizations CA is still checked in the same
place.  subjectAltName field or not.

-- 
Daniel


Mime
View raw message