Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
Name-based virtual hosting doesn't work with https. This means there needs to be one IP
address per web site, which doesn't seem viable until we are all using IPv6.
Posted Jan 3, 2008 8:15 UTC (Thu) by TRS-80 (subscriber, #1804)
Posted Jan 3, 2008 11:48 UTC (Thu) by sitaram (subscriber, #5959)
it's RFC 4366 now
Posted Jan 3, 2008 12:10 UTC (Thu) by redenisc (guest, #43086)
Browsers support for SNI is improving indeed. What about server support
though. OpenSSL supports SNI as of 0.9.9 which is not released at the time
of writing. Hence Apache mod_ssl does not support SNI, hence most deployed
HTTP servers will not support SNI for the next few years.
Posted Jan 3, 2008 13:31 UTC (Thu) by tialaramex (subscriber, #21167)
Bulk hosting is the main application though, and the people doing bulk hosting already have
some guy with a beard and a hand-modified version of Perl working for them so this isn't so
scary. A lot of them still run Linux 2.4, have their own CVS tree for Apache, that sort of
This is the right way round to deploy stuff anyway, you only need one server to provide the
service, but you need as many user agents as possible to support it, or it's useless. If in
2008 just one company, say Dreamhost, offer this as a service, but 95% of people with web
browsers have a new enough one that it supports SNI, then you've got something useful. The
opposite way around would be completely worthless.
Posted Jan 3, 2008 13:55 UTC (Thu) by cortana (subscriber, #24596)
FYI, SNI was backported to OpenSSL 0.9.8g, and there is a patch in Apache's bug tracking
system which works fine in my informal tests (which included backporting OpenSSL 0.9.8g to the
current stable release of Debian, and rebuilding Apache on same--both tasks were nice and
Posted Jan 3, 2008 11:04 UTC (Thu) by DonDiego (subscriber, #24141)
A workaround that I use is to create a certificate for *.site.com, which can then be used for
Posted Jan 3, 2008 12:06 UTC (Thu) by mattdm (subscriber, #18)
I don't think that helps, actually. There's still no way to make the virtual hosts work (short
of RFC 4366 mentioned above).
not exactly true
Posted Jan 3, 2008 17:13 UTC (Thu) by ccyoung (guest, #16340)
if sites on the same ip address share the certificate, then can use rewrite rules to
accomplish pretty much everything you want - or such has been true for me.
Posted Jan 3, 2008 12:07 UTC (Thu) by jschrod (subscriber, #1646)
All recent browsers support the cert extension »Certificate Subject Alt Names«, with DNS names
as entries, and thus allow to use name-based virtual https hosts. We use them on several of
our sites and have had no complaints at all until now. As an example you can look at the cert
of https://lists.dante.de/, our site for the mailing lists of the German TeX Users Group.
Of course, if one still needs to support IE4 or such, one is out of luck.
That said, this is no solution for mass hosters, as one needs to recreate the certificate for
every virtual host that's added. In the end, that is not manageable, especially from a
security viewpoint. But for a company or an organization which has a few dozen hosts and a low
change rate, it's a working solution.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds