On Mon, 2006-03-06 at 13:38 -0500, Eric Covener wrote: > On 3/6/06, Daniel Rogers <[EMAIL PROTECTED]> 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
