java tls_Java客户端中具有SNI的TLS

我正在和ftrotter一样从事同一个项目。

请注意支持数千个域的要求。我不认为SAN会因为两个原因而削减芥末。首先，证书的大小将变得巨大，这可能至少会导致性能问题。其次，这些领域将频繁出现，特别是在NHIN Direct的早期阶段。恕我直言，每当一个域出现或进入时必须更新证书的操作负担将是不可接受的。

在ftrotter的要求下，我做了一些关于java，TLS和SNI主题的搜索，以及实现相当于基于命名的虚拟主机情况的其他方法，每个虚拟主机只有一个证书。这是我想出的：

JSSE(Java安全套接字扩展)支持TLS，并且对TLS + SNI具有“部分支持”。我不知道在这种情况下部分支持意味着什么。我看到的评论表明，存在的支持不足以完成基于命名的虚拟主机，这基本上就是我们所需要的。

我发现有一篇文章声称JSSE的JDK7版本将支持TLS + SNI(日期为2008年11月20日)，而且我发现了一个声称它不会发布的文章(日期为2009年2月27日)。两者都没有特别权威性。

一些致力于OpenJDK 7的人讨论了在2009年2月至3月期间向JSSE添加SNI支持的问题，包括发布源补丁。 (线程从这里开始：

http://www.mail-archive.com/security-dev@openjdk.java.net/msg00612.html)。 OpenJDK7将不会在2010年9月之前的任何时间发布。我不知道Java 7平台什么时候发布。

java.sun.com上没有任何实质内容，所以我真的不知道Sun的计划是什么。

显然有一种不同的方法来完成基于名称的虚拟主机，它显然是广泛兼容的，每个托管服务器使用一个证书，其中包含多个通用名称和多个主题备用名称。请参阅http://wiki.cacert.org/VhostTaskForce并通过连接器为相同的Tomcat应用程序提供不同的证书？

如果您有许多虚拟主机，这种方法将创建非常大的证书(由于所有这些CN和SAN)。 NHIN Direct最近面对面会议的其中一位人士正在谈论想要支持数千个虚拟主机。我的猜测是，这会破坏很多实现。此外，每次添加或删除虚拟主机时都必须更新证书听起来像是一个荒谬的操作负担。

总之，当前基于名称的虚拟主机的Java技术状态似乎是“无法做到”。此外，还不清楚何时或是否会添加。

有人同意或不同意吗？有谁知道OpenJDK项目是否有意“反向移植”对Java 6的SNI支持？