You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Kenevel <ke...@hotmail.com> on 2005/10/25 19:43:00 UTC
NameVirtualHosts & SSL
Hi everyone,
Firstly, this is a topic which may have been endlessly covered before, in
which case I apologise and will go down in flames...
But having referred to the 2.0 docs (well, more like the FAQ) at
http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#vhosts2 I had a thought
about the viability of using SSL with multiple name-based virtual hosts (on
one IP address).
The docs at the URL given above effectively say that hosting more than one
SSL-enabled site using name-based virtual hosting is impossible, as it is
only after the SSL envelope has been decrypted that the server can determine
the "host" value and match this with the ServerName or ServerAlias.
My question is why the server couldn't do some sort of reverse-lookup on its
register of SSL certificates that are in use. Surely the server knows which
certificate it is using to service the request (or else it wouldn't be able
to decrypt its contents) and hence work out which virtual host uses that
certificate? This approach means of course that each name-based virtual host
would have to use a different certificate - but as those sites are more than
likely on different domains the certificates would necessarily be different.
Cheers guys,
Great server.
Mike
Re: NameVirtualHosts & SSL
Posted by Michael Harrison <ke...@hotmail.com>.
Thanks Graham, Joost and Sander, I hadn't expected for Apache to need to
know which virtual host to use so early in the request process.
Cheers
Mike
>From: Sander Temme <sc...@apache.org>
>Reply-To: dev@httpd.apache.org
>To: dev@httpd.apache.org
>Subject: Re: NameVirtualHosts & SSL
>Date: Tue, 25 Oct 2005 11:34:40 -0700
>
>Mike,
>
>On Oct 25, 2005, at 10:43 AM, Kenevel wrote:
>
>
>>My question is why the server couldn't do some sort of reverse- lookup on
>>its
>>register of SSL certificates that are in use. Surely the server knows
>>which
>>certificate it is using to service the request (or else it wouldn't be
>>able
>>
>
>No, it doesn't. At the moment the SSL connection handshake occurs, the
>server needs to present a certificate to the client. The client has
>certain expectations of the Common Name (CN) field of the Distinguished
>Name (DN) string embedded in the certificate, so it is important that the
>server sends the correct certificate.
>
>At this point in the handshake, the server simply doesn't know enough of
>what the client wants, unless the client connects to a distinct IP address
>and the server has a virtual host configured on that IP address.
>Otherwise, the decision on which virtual host to send the request to is
>made way too late.
>
>
>>to decrypt its contents) and hence work out which virtual host uses that
>>certificate? This approach means of course that each name-based virtual
>>host
>>would have to use a different certificate - but as those sites are more
>>than
>>likely on different domains the certificates would necessarily be
>>different.
>>
>
>There is an extension to the TLS ClientHello that allows the client to
>indicate which servername it is trying to connect to: see http://
>www.ietf.org/rfc/rfc3546.txt paragraph 3.1. However, I don't think mod_ssl
>currently supports this. mod_gnutls may be closer, you may want to check
>that out. Of course, until enough of your client base supports this
>extension it is perfectly useless to you.
>
>S.
>
>--
>sander@temme.net http://www.temme.net/sander/
>PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
>
>
><< smime.p7s >>
Re: NameVirtualHosts & SSL
Posted by Sander Temme <sc...@apache.org>.
Mike,
On Oct 25, 2005, at 10:43 AM, Kenevel wrote:
> My question is why the server couldn't do some sort of reverse-
> lookup on its
> register of SSL certificates that are in use. Surely the server
> knows which
> certificate it is using to service the request (or else it wouldn't
> be able
>
No, it doesn't. At the moment the SSL connection handshake occurs,
the server needs to present a certificate to the client. The client
has certain expectations of the Common Name (CN) field of the
Distinguished Name (DN) string embedded in the certificate, so it is
important that the server sends the correct certificate.
At this point in the handshake, the server simply doesn't know enough
of what the client wants, unless the client connects to a distinct IP
address and the server has a virtual host configured on that IP
address. Otherwise, the decision on which virtual host to send the
request to is made way too late.
> to decrypt its contents) and hence work out which virtual host uses
> that
> certificate? This approach means of course that each name-based
> virtual host
> would have to use a different certificate - but as those sites are
> more than
> likely on different domains the certificates would necessarily be
> different.
>
There is an extension to the TLS ClientHello that allows the client
to indicate which servername it is trying to connect to: see http://
www.ietf.org/rfc/rfc3546.txt paragraph 3.1. However, I don't think
mod_ssl currently supports this. mod_gnutls may be closer, you may
want to check that out. Of course, until enough of your client base
supports this extension it is perfectly useless to you.
S.
--
sander@temme.net http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: NameVirtualHosts & SSL
Posted by Sander Temme <sa...@temme.net>.
Mike,
On Oct 25, 2005, at 10:43 AM, Kenevel wrote:
> My question is why the server couldn't do some sort of reverse-
> lookup on its
> register of SSL certificates that are in use. Surely the server
> knows which
> certificate it is using to service the request (or else it wouldn't
> be able
No, it doesn't. At the moment the SSL connection handshake occurs,
the server needs to present a certificate to the client. The client
has certain expectations of the Common Name (CN) field of the
Distinguished Name (DN) string embedded in the certificate, so it is
important that the server sends the correct certificate.
At this point in the handshake, the server simply doesn't know enough
of what the client wants, unless the client connects to a distinct IP
address and the server has a virtual host configured on that IP
address. Otherwise, the decision on which virtual host to send the
request to is made way too late.
> to decrypt its contents) and hence work out which virtual host uses
> that
> certificate? This approach means of course that each name-based
> virtual host
> would have to use a different certificate - but as those sites are
> more than
> likely on different domains the certificates would necessarily be
> different.
There is an extension to the TLS ClientHello that allows the client
to indicate which servername it is trying to connect to: see http://
www.ietf.org/rfc/rfc3546.txt paragraph 3.1. However, I don't think
mod_ssl currently supports this. mod_gnutls may be closer, you may
want to check that out. Of course, until enough of your client base
supports this extension it is perfectly useless to you.
S.
--
sander@temme.net http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: NameVirtualHosts & SSL
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
William A. Rowe, Jr. wrote:
> Ondrej Sury wrote:
>>
>> Just a thought... Wouldn't it be possible to solve this by extending
>> HTTP to support something similar to STARTTLS from IMAP/SMTP?
>
> Dudes, it's already published in http://rfc.net/rfc2818.html - yet it seems
> my mailbox fills with another 100k of this discussion every month (mostly
> on users@httpd). It's not worth reinventing twice.
As a footnote, it's actually http://rfc.net/rfc2817.html as-implemented.
Re: Support for Server Name Indication (Was: NameVirtualHosts & SSL)
Posted by Paul Querna <ch...@force-elite.com>.
Ruediger Pluem wrote:
>
> On 11/09/2005 11:38 AM, Ondrej Sury wrote:
>> On Tue, 2005-11-08 at 11:24 -0600, William A. Rowe, Jr. wrote:
>>
>>> Ondrej Sury wrote:
>>>
>
> [..cut..]
>
>> Alternate approach is to use Server Name Indication TLS extension as
>> specified by: http://rfc.net/rfc3546.html and covered by
>
> Does anybody know if the latest openssl provides enough features to implement
> rfc3546 with httpd?
It does not. (yet).
The only open source toolkit that does is GnuTLS. Hence, this feature is
only available in my mod_gnutls.
-Paul
Re: Support for Server Name Indication (Was: NameVirtualHosts & SSL)
Posted by Ruediger Pluem <rp...@apache.org>.
On 11/09/2005 11:38 AM, Ondrej Sury wrote:
> On Tue, 2005-11-08 at 11:24 -0600, William A. Rowe, Jr. wrote:
>
>>Ondrej Sury wrote:
>>
[..cut..]
>
> Alternate approach is to use Server Name Indication TLS extension as
> specified by: http://rfc.net/rfc3546.html and covered by
Does anybody know if the latest openssl provides enough features to implement
rfc3546 with httpd?
[..cut..]
Regards
Rüdiger
Support for Server Name Indication (Was: NameVirtualHosts & SSL)
Posted by Ondrej Sury <on...@sury.org>.
On Tue, 2005-11-08 at 11:24 -0600, William A. Rowe, Jr. wrote:
> Ondrej Sury wrote:
> >
> > Just a thought... Wouldn't it be possible to solve this by extending
> > HTTP to support something similar to STARTTLS from IMAP/SMTP?
>
> Dudes, it's already published in http://rfc.net/rfc2818.html - yet it seems
> my mailbox fills with another 100k of this discussion every month (mostly
> on users@httpd). It's not worth reinventing twice.
>
> Read the RFC, and take it to your favorite browser vendor/author/project.
> If open source - offer a patch already to them.
>
> Go solve it - quit writing here about it :) In three years after widely
> distributed, we could quit deploying 1:1 IP's per host.
There is already bug in mozilla bugzilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=276813
Alternate approach is to use Server Name Indication TLS extension as
specified by: http://rfc.net/rfc3546.html and covered by
https://bugzilla.mozilla.org/show_bug.cgi?id=116168 and it will be
implemented in upcomming IE7
http://blogs.msdn.com/ie/archive/2005/10/22/483795.aspx
Ondrej.
--
Ondrej Sury <on...@sury.org>
Re: NameVirtualHosts & SSL
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Ondrej Sury wrote:
>
> Just a thought... Wouldn't it be possible to solve this by extending
> HTTP to support something similar to STARTTLS from IMAP/SMTP?
Dudes, it's already published in http://rfc.net/rfc2818.html - yet it seems
my mailbox fills with another 100k of this discussion every month (mostly
on users@httpd). It's not worth reinventing twice.
Read the RFC, and take it to your favorite browser vendor/author/project.
If open source - offer a patch already to them.
Go solve it - quit writing here about it :) In three years after widely
distributed, we could quit deploying 1:1 IP's per host.
Bill
Re: NameVirtualHosts & SSL
Posted by Graham Leggett <mi...@sharp.fm>.
Ondrej Sury said:
> Just a thought... Wouldn't it be possible to solve this by extending
> HTTP to support something similar to STARTTLS from IMAP/SMTP?
Very possible yes, HTTP already has support for this, as does httpd v2.2.
The trouble is the browsers don't (yet), so until there is widespread
support from that side, it's not practical.
It is however the most likely solution to emerge should the browsers
decide to start supporting it.
Regards,
Graham
--
Re: NameVirtualHosts & SSL
Posted by Ondrej Sury <on...@sury.org>.
On Tue, 2005-10-25 at 20:25 +0200, Joost de Heer wrote:
> > The one-virtual-host-per-ip limitation is imposed by SSL, it has nothing
> > to do with the webserver.
>
> <nitpick>
> one-virtual-host-per-ip-and-port
> </nitpick>
Just a thought... Wouldn't it be possible to solve this by extending
HTTP to support something similar to STARTTLS from IMAP/SMTP?
Ie. instead of submitting:
GET / HTTP/1.0
Host: foobar.tld
browser would do:
STARTTLS foobar.tld
<encrypted comm>
Ondrej.
--
Ondrej Sury <on...@sury.org>
Re: NameVirtualHosts & SSL
Posted by Joost de Heer <jo...@sanguis.xs4all.nl>.
> The one-virtual-host-per-ip limitation is imposed by SSL, it has nothing
> to do with the webserver.
<nitpick>
one-virtual-host-per-ip-and-port
</nitpick>
> There is an exception - if you use a wildcard certificate, you can run
> multiple virtual hosts on condition all the virtual hosts match the
> wildcard certificate.
Another exception is if you don't care about the popup warning, and only use
certificates for encryption, and not for identification of the webserver.
Joost
Re: NameVirtualHosts & SSL
Posted by Graham Leggett <mi...@sharp.fm>.
Kenevel wrote:
> My question is why the server couldn't do some sort of reverse-lookup on its
> register of SSL certificates that are in use. Surely the server knows which
> certificate it is using to service the request (or else it wouldn't be able
> to decrypt its contents) and hence work out which virtual host uses that
> certificate?
The server knows exactly this, yes, but by then it is too late.
The one-virtual-host-per-ip limitation is imposed by SSL, it has nothing
to do with the webserver.
There is an exception - if you use a wildcard certificate, you can run
multiple virtual hosts on condition all the virtual hosts match the
wildcard certificate.
Regards,
Graham
--