I read this article and still don't understand the issue.
If I understand correctly the client negotiates after the first SSL connection and then gets the correct hostname and thus correct certificate.
http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI
To their credit I know I'm not using SNI becuase I get this message in the Apache log :)
[warn] Init: You should not use name-based virtual hosts in conjunction with SSL!!
But once again I don't get the issue. SSL works fine with my name based vhosts and allows me to use a shared certificate by default and if I want a "real certificate" I just buy another IP from my provider, assign it to the right domain and buy the new certificate and set it up.
To put it in perspective I've used this for years on my own manual websites, using Name Based vhosts and a shared SSL certificate AND sites with separate IPs that have their own without issue. SNI sounds like it is not as widely as supported by clients as normal SSL connections.
I guess the only real benefit of SNI is the ability to serve multiple unique certificates without a separate IP being required, but I don't see this being an issue for most people unless they're on a real budget.
I do agree at some point in the future it may be a problem, but by then IPV6 should be widely adopted and IPs will no longer again be an issue.
apache, sni, correctly, negotiates, ssl, hostname, thus, certificate, http, wiki, org, httpd, namebasedsslvhostswithsni, becuase, init, virtual, hosts, conjunction, vhosts, allows, default, quot, ip, provider, assign, domain, ve, manual, websites, sites, ips, widely, supported, connections, multiple, certificates, ipv,