User: Password:
Subscribe / Log in / New account

another drawback

another drawback

Posted Jan 3, 2008 4:57 UTC (Thu) by mattdm (subscriber, #18)
Parent article: The future of unencrypted web traffic

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.

(Log in to post comments)

another drawback

Posted Jan 3, 2008 8:15 UTC (Thu) by TRS-80 (subscriber, #1804) [Link]

Firefox 2, Opera 8 and IE7 (on Vista) all support TLS SNI (RFC 3546), so it's probably feasible to start deploying widely in a year or two (which is sooner than IPv6 will become mainstream). Try out your browser at

another drawback

Posted Jan 3, 2008 11:48 UTC (Thu) by sitaram (guest, #5959) [Link]

it's RFC 4366 now

another drawback

Posted Jan 3, 2008 12:10 UTC (Thu) by redenisc (guest, #43086) [Link]

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.

another drawback

Posted Jan 3, 2008 13:31 UTC (Thu) by tialaramex (subscriber, #21167) [Link]

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.

another drawback

Posted Jan 3, 2008 13:55 UTC (Thu) by cortana (subscriber, #24596) [Link]

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
easy). :)


Posted Jan 3, 2008 11:04 UTC (Thu) by DonDiego (guest, #24141) [Link]

A workaround that I use is to create a certificate for *, which can then be used for
all subdomains.


Posted Jan 3, 2008 12:06 UTC (Thu) by mattdm (subscriber, #18) [Link]

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) [Link]

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.

another drawback

Posted Jan 3, 2008 12:07 UTC (Thu) by jschrod (subscriber, #1646) [Link]

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, 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 © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds