Re: SSL enabled name virtual hosts
Daniel Rogers wrote: However, this seems like an artifact of the config file data data organization and/or an apache implementation limitation, rather than a limitation on the protocol itself. I would just ignore the troll, but you have put the time into trying to think this through, so we repeat... ClientServer request handshake --> acknowledge handshake negotiate keys and credentials connection secure<-- complete handshake now encrypted... send headers (Host:) --> read headers, choose a virtual host read response<-- prepare response The client and server agreed upon a certificate before Host: was seen. No problem, right? Only issue is for the client, it thinks that example.com isn't example.net as recorded in the common name. We can't vary on Host: before we see Host:, and we won't see Host: till handshake is complete. Stop bitching about a 10 year old spec. It's trivial, use a modern browser (beyond today - none exist yet) that can do Connection-Upgrade and agree about the text of the headers before the ssl handshake is performed. The browser people haven't caught up, because it's a non-trivial problem to represent that the agreed-upon connection is secure to the user, or that a secure connection is available to be toggled, or whatever. These aren't https:// requests, they are http:// with extra semantics. Modern clients such as remote printing over http and neon/curl libraries already support it now, IIUC. As does httpd 2.2.
RE: SSL enabled name virtual hosts
> -Original Message- > From: Daniel Rogers [mailto:[EMAIL PROTECTED] > Sent: Montag, 6. März 2006 03:17 > To: dev@httpd.apache.org > Subject: SSL enabled name virtual hosts > > > I am not convinced by the argument that name based SSL virtual hosting > is impossible. It's not only an argument, it's a demonstrable fact. I did read your posting and you clearly do understand a good deal about HTTP but there are a couple of key points that are leading you to wrongthink: - You're right that since apache can't see the host header, it uses the cert from the default VH to establish the SSL session. Thereafter, it *can* see the host header and so can route the requests successfully. This give a lot of people the illusion that SSL-NBVH is possible. The big problem is that you don't get authentication because the default cert, generally, will not match the requested site. For professional SSL, authentication is every bit as essential as encryption so this won't do. - Using an extra port (444, etc) immediately gives you access to multiple SSL VHs. But they are then port-based VHs, not name-based. SSL VHs have to be distinct at the TCP/IP layer, so changing ports achieves that. NBVHs are degenerate at TCP/IP and only distinct at HTTP. But using an extra port is not a professional solution - anything other than port 80 and 443 will not wash on the commercial internet. - Using SubjectAltName to allow for an "all-purpose" certificate sounds like a good idea and would be fine in a research environment where you are making your own certs. But I don't think it would be very practical in a commercial situation. If you are a web-hosting company, are you really going to get a new certificate every time a site wants an SSL VH? Who sells these certs? How expensive are they? As has been pointed out, the problem is already solved at the technical level by upgrading to TLS within HTTP/1.1 (rfc 2817). The real problem is waiting for browsers to support it... Rgds, Owen Boyle Disclaimer: Any disclaimer attached to this message may be ignored. > Yes. I understand that in order to > understand your ssl > configuration you need to pick a virtual host context. Since > you don't > have the hostname the server was requested as at the time of the SSL > negotiation, you end up falling through to the default SSL host. > > However, this seems like an artifact of the config file data data > organization and/or an apache implementation limitation, rather than a > limitation on the protocol itself. > > For example: > Suppose I wanted to mangle apache into doing something like name > virtual hosting for SSL enabled clients. Here is how I envision this > being possible: > > - Tell apache to listen on a new port (say, 444). > - For the default first host on port 443, I create a script, > which reads > the http Host: header and then issues the exact same request > on port 444 > of the machine and echo's the output. > - Now create name based virtual host definitions for port 444 anywhere > you would like to have name based SSL virtual hosts. > > Granted, there are some pretty serious limitations with this design. > For example: > > -you would probably only want port 444 available from local interfaces > (which can be enforced with a firewall). > > -you can't create access rules based on ip address or ssl status from > within apache. > > -You need to filter the response headers to keep up the facade, as it > were. (for example, making sure you filter redirects to > redirect to the > proxy script and not what the virtual host thinks it is). > > -the named based virtual SSL hosts would effectively all have the > same SSL certificate. This, however, can be dealt effectively and > completely with the SubjectAltName field of the server cert. > > -numerous other issues with the documents you are serving > being shown a > different port number than is actually being served. > > This would have the effect that people are looking for. One > ssl enabled > host, which presents a different DocumentRoot based on the Host: http > header. The code to do this would only be a few hundred > lines in php or > perl, if you rely on an already existing http request class. > > However, I don't see why this couldn't be implemented in apache, and > remove all the limitations I mentioned above, except for the > need for a > certificate with a subjectAltName. For example, suppose you have a > second name virtual host style configuration directive that > looked something like: > > > /all ssl options here/ > > > Then, instead of picking a virtual host definition in order to be able > to negotiate the SSL session, the SSLNameVirtualHost statement would > have all that it needed to negotiate the SSL session, then, after the > SSL session is negotiated, the virtual host definitions could be > consulted for a suitable virtual host to serve to the client. This > would allow the virtual host to define access contro
Re: SSL enabled name virtual hosts
On Monday 06 March 2006 02:16, Daniel Rogers wrote: > I am not convinced by the argument that name based SSL virtual hosting > is impossible. [chop] You might want to look at the demo at https://sni.corelands.com/ . SSL virtual hosting with mod_gnutls, and a test to see whether your browser supports it. -- Nick Kew
Re: SSL enabled name virtual hosts
Boyle Owen wrote: - You're right that since apache can't see the host header, it uses the cert from the default VH to establish the SSL session. Thereafter, it *can* see the host header and so can route the requests successfully. This give a lot of people the illusion that SSL-NBVH is possible. The big problem is that you don't get authentication because the default cert, generally, will not match the requested site. For professional SSL, authentication is every bit as essential as encryption so this won't do. We use a "wildcard cert" to overcome this situation... the technical limitation is that all the SSL "hosts" have to end with the same domain (a wildcard cert is bound to our domain, not any individual host name), but otherwise we can and do indeed run hundreds (soon to be thousands) of customers on their own individual host names under SSL, all on port 443 on one instance of apache. Unfortunately we have to do funny mod_rewrite trickery to simulate NBVH instead of using real NBVH I suspect it would be a major change in Apache architecture to use real NBVH in our case (but otherwise, yes, it absolutely could be technically possible, given the all-must-be-in-the-same-domain, and must use a "wildcard cert" limitations). Dave
RE: SSL enabled name virtual hosts
> -Original Message- > From: David Burry [mailto:[EMAIL PROTECTED] > Sent: Montag, 6. März 2006 11:08 > To: dev@httpd.apache.org > Subject: Re: SSL enabled name virtual hosts > > > We use a "wildcard cert" to overcome this situation... the technical > limitation is that all the SSL "hosts" have to end with the > same domain Absolutely. I've no doubt this indeed works - there is nothing in the protocol to prevent it doing so. How did you get your wildcard cert? Did you buy it? Apparently, the cert sellers (Thwate, Versign etc.) are not too keen on selling wildcards for the simple reason that it reduces the number of certs required (and hence sold) - a bit like the everlasting light bulb... Was that your experience? My understanding is that most people using this solution are using self-signed certs and are in a non-commercial operation. I guess a commercial vendor could use it if they wanted to compartmentalise their trade (eg, books.amazon.com, dvds.amazon.com, software.amazon.com, etc.) Rgds, Owen Boyle Disclaimer: Any disclaimer attached to this message may be ignored. PS - as Nick points out, Server Name Indication is also a method to achieve SSL-NBVH but, again, is waiting for browser support (I couldn't get it to work even with Opera 8.5 on XP :-( > (a wildcard cert is bound to our domain, not any individual > host name), > but otherwise we can and do indeed run hundreds (soon to be > thousands) > of customers on their own individual host names under SSL, > all on port > 443 on one instance of apache. Unfortunately we have to do funny > mod_rewrite trickery to simulate NBVH instead of using real > NBVH I > suspect it would be a major change in Apache architecture to use real > NBVH in our case (but otherwise, yes, it absolutely could be > technically > possible, given the all-must-be-in-the-same-domain, and must use a > "wildcard cert" limitations). > > Dave > > Diese E-mail ist eine private und persönliche Kommunikation. Sie hat keinen Bezug zur Börsen- bzw. Geschäftstätigkeit der SWX Gruppe. This e-mail is of a private and personal nature. It is not related to the exchange or business activities of the SWX Group. Le présent e-mail est un message privé et personnel, sans rapport avec l'activité boursière du Groupe SWX. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
Re: SSL enabled name virtual hosts
Boyle Owen wrote: -Original Message- From: David Burry [mailto:[EMAIL PROTECTED] We use a "wildcard cert" to overcome this situation... How did you get your wildcard cert? Did you buy it? Apparently, the cert sellers (Thwate, Versign etc.) are not too keen on selling wildcards for the simple reason that it reduces the number of certs required (and hence sold) - a bit like the everlasting light bulb... Was that your experience? Yes, it was bought... So far the experience has been awesome (other than the previously mentioned apache architecture limitation workarounds). There are some cert sellers out there who are getting competitive in this respect, maybe not the original big guys such as the ones you mention yet, but it would be absolutely impossible for us to do what we're doing right now without this kind of cert, it's not feasible to buy a class B block of IP addresses and we couldn't afford that many individual certs unless they were only a couple bucks apiece or less! Dave
RE: SSL enabled name virtual hosts
On Mon, 2006-03-06 at 10:25 +0100, Boyle Owen wrote:
> > -Original Message-
> > From: Daniel Rogers [mailto:[EMAIL PROTECTED]
> > Sent: Montag, 6. März 2006 03:17
> > To: dev@httpd.apache.org
> > Subject: SSL enabled name virtual hosts
> >
> >
> > I am not convinced by the argument that name based SSL virtual hosting
> > is impossible.
>
> It's not only an argument, it's a demonstrable fact.
>
> I did read your posting and you clearly do understand a good deal about
> HTTP but there are a couple of key points that are leading you to
> wrongthink:
>
> - Using an extra port (444, etc) immediately gives you access to multiple
> SSL VHs. But they are then port-based VHs, not name-based. SSL VHs have
> to be distinct at the TCP/IP layer, so changing ports achieves that.
> NBVHs are degenerate at TCP/IP and only distinct at HTTP. But using an
> extra port is not a professional solution - anything other than port 80
> and 443 will not wash on the commercial internet.
I don't think you understand what I did. Let me explain with some
apache configuration snippets:
DocumentRoot "/var/www/html-secure"
AliasMatch .* /var/www/html-secure/index.php
SSLEngine on
/SSL options/
Listen 444
Listen 80
NameVirtualHost *:444
NameVirtualHost *:80
/virt host options/
ServerName example.com
/virt host options/
ServerName example2.net
Contents of index.php:
Request.php is based on the pear module HTTP_Request, modified so
that the header names are stored without being converted to lower case.
This is not a complete implementation. It only works for GET and HEAD
requests. And redirects are not filtered.
setMethod($_SERVER["REQUEST_METHOD"]);
$req->sendRequest();
$code = $req->getResponseCode();
header(HTTPStatus($code));
foreach ($req->getResponseHeader() as $name => $value) {
header($name . ": " . $value, true);
}
if ($_SERVER["REQUEST_METHOD"] != "HEAD") {
echo $req->getResponseBody();
}
/**
* HTTP Protocol defined status codes
* snipped from the user comments in the php manual
* @param int $num
*/
function HTTPStatus($num) {
static $http = array (
100 => "HTTP/1.1 100 Continue",
101 => "HTTP/1.1 101 Switching Protocols",
200 => "HTTP/1.1 200 OK",
201 => "HTTP/1.1 201 Created",
202 => "HTTP/1.1 202 Accepted",
203 => "HTTP/1.1 203 Non-Authoritative Information",
... the rest of the status codes ...
return $http[$num];
}
?>
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.
The end user sees only port 443. No worries about weird port numbers.
> - You're right that since apache can't see the host header, it uses the
> cert from the default VH to establish the SSL session. Thereafter,
> it *can* see the host header and so can route the requests successfully.
> This give a lot of people the illusion that SSL-NBVH is possible. The
> big problem is that you don't get authentication because the default cert,
> generally, will not match the requested site. For professional SSL,
> authentication is every bit as essential as encryption so this won't do.
>
> - Using SubjectAltName to allow for an "all-purpose" certificate sounds
> like a good idea and would be fine in a research environment where you
> are making your own certs. But I don't think it would be very practical
> in a commercial situation. If you are a web-hosting company, are you
> really going to get a new certificate every time a site wants an SSL VH?
> Who sells these certs? How expensive are they?
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. I don't think the argument you present, that
it's not worth implementing a feature because noone sells a certificate
that would work with it, holds water. What motivation does any
certificate seller have to even offer a licensing scheme that works with
a feature no one can use because it doesn't exist.
These companies are not stupid. If customers repeatedly came to
Verisign (or any other certificate company) and said:
Me: Verisign, I need a multi-host certificate. I am willing to pay the
same price as multiple certificates for multiple hosts, but I need you
to make me a single certificate for all those hosts.
Verisign: Why should we?
Me: Because apache has a new feature to allow name based SSL virtual
hosts, but only if those hosts are specified in a subjectAltName
Verisign: And if we don't?
Me: I'll keep asking someone else until someone says yes. Also, there
are about to be 1000 more like me.
Verisign: Well, we talked about it and we think it will cost you 5
percent more this way (bwa ha ha)!
Me: Great! I'm a hosting company and can now offer an incredible
feature to our clients, besides I just passed the cost
Re: SSL enabled name virtual hosts
Daniel Rogers wrote: Your two arguments, in short, are, no one sells certificates for that feature, and there is a technical solution already. Well, the feature doesn't exist (even though it could, I MADE IT WORK. IT WORKS FOR ME.), so why sell certificates for it, and the technical solution is not compatible with current browser so it is _years_ away. Demonstration - please, if you truly believe this just works. URI? I'd be happy to attempt to connect using firefox/safari/IE. Bill
Re: SSL enabled name virtual hosts
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? Don't you get this same "solution" with 1 RewriteRule (proxied, not redirected) and a certificate crafted the way you describe? > 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? -- Eric Covener [EMAIL PROTECTED]
Re: SSL enabled name virtual hosts
Daniel Rogers 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. The end user sees only port 443. No worries about weird port numbers. Of course this works for the server. So do named based port 443 servers on the server side today. You don't need all this PHP script - httpd's VirtualHost mechanics work (so does mass vhosting via module or rewrite.) What you failed to address in your example is that *one and only one* certificate is used to handshake to port 443. - Using SubjectAltName to allow for an "all-purpose" certificate sounds like a good idea and would be fine in a research environment where you are making your own certs. But I don't think it would be very practical in a commercial situation. If you are a web-hosting company, are you really going to get a new certificate every time a site wants an SSL VH? Who sells these certs? How expensive are they? 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. Then use this today as the primary certificate of a normal name-based vhost solution, with the subjectAltNames of all the certificates. If that really works for browsers today, that's lovely. What is missing here is that if I'm a mass vhosting service of joesrepairs.com, tomsgarage.com, salliessewingcircle.com, parentsformorality.org and xxx.com, I don't know that the parents really want their site associated with a porn site, while tom and joe across the street from each other might have an issue as well. If you use the subjectAltName you need to list *all* these on your single physical IP/port which is used for the *one* certificate that the server presents to the client for handshaking. Certainly, if you are serving support.mycompany.com, downloads.mycompany.com, and www.affiliate.com, then this might be a lovely solution. Also, I don't appreciate being called a troll. I am trying to make reasoned articulate arguments. I haven't insulted anyone, and I am really making an effort to understand the arguments people are presenting me. To be clear, all of this has been rehashed weekly for years. Everyone thinks they invented the next best thing since sliced bread to work around these constraints, while asking us to spend our time explaining the constraints -again- each time. Unlike most others, you obviously thought on this alot and deserved a response for your efforts. subjectAltName and wildcard certs might be an option for some, so perhaps the documentation needs to be revised if, in fact, the subjectAltName solution is supported by all modern browsers (or most with explicit exceptions.) But don't confuse either subjectAltName or a wildcard cert for adding more arbitrary certificates for each individual name-based virtual host. The certificate has been presented. It's also possible, perhaps, that you can move from the original cert to a replacement cert of that individual site alone, by creating both a master cert of all subjectAltName entries as well as an individual cert of the single commonName. Simply force a renegotation. Yet and still, the browser/client/user -will- be presented one and only one certificate when connecting to a given IP/port of an https server, and this fact cannot be avoided without either TLS name handshaking or plain text connection-upgrade to a secure connection. Yours, Bill
Re: SSL enabled name virtual hosts
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: /all ssl options here/ 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
Re: SSL enabled name virtual hosts
On Mon, 2006-03-06 at 12:40 -0600, William A. Rowe, Jr. wrote: > Daniel Rogers wrote: > > > What you failed to address in your example is that *one and only one* > certificate is used to handshake to port 443. > > >>- Using SubjectAltName to allow for an "all-purpose" certificate sounds > >>like a good idea and would be fine in a research environment where you > >>are making your own certs. But I don't think it would be very practical > >> in a commercial situation. If you are a web-hosting company, are you > >>really going to get a new certificate every time a site wants an SSL VH? > >> Who sells these certs? How expensive are they? > > > > 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. > > Then use this today as the primary certificate of a normal name-based > vhost solution, with the subjectAltNames of all the certificates. If that > really works for browsers today, that's lovely. > > What is missing here is that if I'm a mass vhosting service of > joesrepairs.com, > tomsgarage.com, salliessewingcircle.com, parentsformorality.org and xxx.com, > I don't know that the parents really want their site associated with a porn > site, while tom and joe across the street from each other might have an issue > as well. If you use the subjectAltName you need to list *all* these on your > single physical IP/port which is used for the *one* certificate that the > server > presents to the client for handshaking. Ah ha!! I see, said the blind man. So I've used this subjectAltName for Dovecot, postfix and httpd simultanously. It works with Mozilla/Firefox, Mail.app, Thunderbird, Safari, and evolution. I haven't check with IE. Though if anyone wants to you can check these ssl sites, which all present the same certificate. (the page itself gives a link to the CA cert, if you'd like to check that part too). No virtual hosting is going on here, so you see the same site with all of them. https://spike.phasevelocity.org/ https://phasevelocity.org/ https://www.phasevelocity.org/ With firefox, or any of the programs I mentioned above, I get no hostname mis-matched error. I think the more insidious problem is that no tools I've used so far actually show the subjectAltName hostnames without delving into the certificate details, and looking for it, in particular. If you actually perform a cursory examination the certificate once you've connected to site, it only shows the commonName of the cert, which might be totally unrelated to the hostname to connected to. Even though, if you trust the CA, it accepts the cert as valid, which would be very disconcerting if you were not expecting it. If fact, as I just checked, I don't think it is possible to get a human readable form of the subjectAltName field at all from within the Firefox certificate examination dialog. Thus there is no way to examine the certificate from within firefox, and actually verify, even in an obscure way, that the certificate is valid for this host, even though Firefix will accept the certificate as valid and present no host-mismatched error. Disconcerting indeed! > To be clear, all of this has been rehashed weekly for years. Everyone thinks > they invented the next best thing since sliced bread to work around these > constraints, while asking us to spend our time explaining the constraints > -again- each time. Unlike most others, you obviously thought on this alot > and deserved a response for your efforts. subjectAltName and wildcard > certs might be an option for some, so perhaps the documentation needs to be > revised if, in fact, the subjectAltName solution is supported by all modern > browsers (or most with explicit exceptions.) Hmm, I feel it is certainly worth exploring whether or not subjectAltName works in IE. > But don't confuse either subjectAltName or a wildcard cert for adding more > arbitrary certificates for each individual name-based virtual host. The > certificate has been presented. It's also possible, perhaps, that you can > move from the original cert to a replacement cert of that individual site > alone, by creating both a master cert of all subjectAltName entries as well > as an individual cert of the single commonName. Simply force a renegotation. > Yet and still, the browser/client/user -will- be presented one and only one > certificate when connecting to a given IP/port of an https server, and this > fact cannot be avoided without either TLS name handshaking or plain text > connection-upgrade to a secure connection. Indeed, there is no arguing on that point. Then I suppose my proper course of action is to: 1. Demonstrate a working NameVirtualHost, single cert SSL configuration. 2. Verify that it works in most browsers 3. Update the FAQ and documentation as to the limitations, and the need for special certificates. Thanks Bill and Owen, for making taking the time to make this c
Re: SSL enabled name virtual hosts
Daniel Rogers wrote: Hmm, I feel it is certainly worth exploring whether or not subjectAltName works in IE. http://wiki.cacert.org/wiki/VhostTaskForce All of your issues are covered there. With that said, find an authority who's willing to sign whatever solution you come up with. Lots of thorny issues are pointed out at that page. Yours, Bill
RE: SSL enabled name virtual hosts
> -Original Message- > From: Daniel Rogers [mailto:[EMAIL PROTECTED] > Sent: Montag, 6. März 2006 19:01 > > > The end user sees only port 443. No worries about weird port numbers. Ok - I read the post and I agree your solution doesn't rely on using a non-standard port externally. I was confused by the complicated redirecting scheme which, as you've now learned, can be more easily implemented in mod_rewrite. In any case, I don't know why you need it at all since, once you have an SSL session running, you can just use the NBVH mechanism to route requests to the appropriate VH. Your solution relies entirely on the existence of a certificate with multiple host-names. If you have this, then you can present it as the single default certificate for every SSL session and then (since the cert contains all host names) the browser does not complain about a URL vs. CN mismatch. Nobody would dispute that this mechanism would work - there's nothing in the protocol to prevent it. The problem, as William pointed out, is getting and managing the certificate. As you say, Verisign would need to get into the business of selling such certs, along with a mechanism for allowing the owner to load new sites (essential for a web-hoster). Bearing in mind that Verisign et al are supposed to verify the identity of the requester of a cert before issuing it, how would you propose that works? I guess you'd need a new scheme whereby the cert would contain a pointer to Verisign who would maintain the list of authenticated SubjectAltNames. Maybe you're right, maybe Verisign would like to get involved in that business - but it's clearly something for the future... I've no doubt that in an academic environment, where you are your own certificate authority and are making self-signed certs, this could be useful. But I think you're skipping over the importance of authentication in real-world, commercial SSL. To sum up: your solution doesn't do anything new and, although technically possible, doesn't work in the real world because the certificate management scheme doesn't exist. Further, there are at least two "competing" schemes (server name indication and HTTP upgrade to TLS) that are already in the pipeline - oh, and don't forget IPv6... Rgds, Owen Boyle Disclaimer: Any disclaimer attached to this message may be ignored. > Also, I don't appreciate being called a troll. I'm sure you don't, but I never said that. > > > Diese E-mail ist eine private und persönliche Kommunikation. Sie hat keinen Bezug zur Börsen- bzw. Geschäftstätigkeit der SWX Gruppe. This e-mail is of a private and personal nature. It is not related to the exchange or business activities of the SWX Group. Le présent e-mail est un message privé et personnel, sans rapport avec l'activité boursière du Groupe SWX. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
