为什么Java6接收的SSL证书链与Java7不同？

我们已经重新配置了一台服务器，以更改其中一台虚拟主机的主机名

我们的服务器配置来自：

<VirtualHost *:443>
    ServerName test.olddomain.com

    SSLEngine on
    SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

    SSLCertificateFile "D:/Security/wildcard/OLDDOMAIN.COM.crt"
    SSLCertificateKeyFile "D:/Security/wildcard/OLDDOMAIN.COM.key"
    SSLCertificateChainFile "D:/Security/wildcard/CertChain.crt"

    ...
</VirtualHost>

我尝试使用-Djavax.net.debug=SSL选项运行java，奇怪的是java获得了旧域的证书：

*** Certificate chain
chain [X] = [
[
  Version: VX
  Subject: CN=*.olddomain.com, O=COMPANY, L=Place, ST=ST, C=US
  Signature Algorithm: SHAXwithRSA, OID = X.X.XXX.XXXXXX.X.X.X

  Key:  Sun RSA public key, XXXX bits
  modulus:     XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXX
  public exponent: XXXXX
  Validity: [From: Tue Jan XX XX:XX:XX EST XXXX,
               To: Fri Feb XX XX:XX:XX EST XXXX]
  Issuer: CN=DigiCert High Assurance CA-X, OU=www.digicert.com, O=DigiCert Inc, C=US
  SerialNumber: [    XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX]

但是，如果我用java7替换java6。它正确地读取了正确的证书，并且我能够访问URL

我错过了什么？我确实看到从java6到java7的握手略有不同，但我不认为这可以解释获得不同证书的原因

Java6握手：

*** ClientHello, TLSv1
***
pool-1-thread-1, WRITE: TLSv1 Handshake, length = 95
pool-1-thread-1, WRITE: SSLv2 client hello message, length = 131
pool-1-thread-1, READ: TLSv1 Handshake, length = 81
*** ServerHello, TLSv1
Cipher Suite: SSL_RSA_WITH_RC4_128_MD5
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: <empty>
***
%% Created:  [Session-4, SSL_RSA_WITH_RC4_128_MD5]
** SSL_RSA_WITH_RC4_128_MD5
pool-1-thread-1, READ: TLSv1 Handshake, length = 4313

*** ClientHello, TLSv1
Extension elliptic_curves, curve names: {secp256r1, sect163k1, sect163r2, secp192r1, secp224r1,sect233k1, sect23
 sect409k1, sect409r1, secp521r1, sect571k1, sect571r1, secp160k1, secp160r1, secp160r2,  sect163r1, secp192k1, se9k1,     secp256k1}
Extension ec_point_formats, formats: [uncompressed]
Extension server_name, server_name: [host_name: test.newdomain.com]
***
pool-5-thread-2, WRITE: TLSv1 Handshake, length = 181
pool-5-thread-2, READ: TLSv1 Handshake, length = 85
*** ServerHello, TLSv1
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA
Compression Method: 0
Extension server_name, server_name:
Extension renegotiation_info, renegotiated_connection: <empty>
***
%% Initialized:  [Session-1, TLS_RSA_WITH_AES_128_CBC_SHA]
** TLS_RSA_WITH_AES_128_CBC_SHA
pool-5-thread-2, READ: TLSv1 Handshake, length = 4312

---

谢谢

根据汤普森085号提供的输入回答我自己的问题

问题是请求总是使用IP地址发送，主机名包含在http头中。但是，使用SSL时，主机名信息是加密的。因此，当SSL握手发生时，它还不知道主机名。正因为如此，它不知道请求应该转到哪个虚拟主机并返回第一个（或默认）证书，在我们的示例olddomain.com中，哪个是错误的

---

浏览器和java7之所以不受影响，是因为它们将服务器名称指示（SNI）作为SSL信息的一部分发送。这样，apache在启动SSL握手之前就知道要使用哪个虚拟主机，并返回正确的证书。Java 6不支持SNI。

区别无疑是因为java7（Https）URLCON和（所有？主要？）浏览器一样，发送服务器名称指示（SNI），但正如调试输出所证实的，java6不支持。命名的vhost服务器需要SNI来指定所需的主机和证书，如果没有SNI，则必须执行一些默认操作，这在您的情况下显然是错误的，但我不知道足够的httpd来说明具体的查找位置。非常感谢您的评论。我们一直在思考这些问题，但我不知道SNI。至少我现在有事情要调查。再次感谢！

*** ClientHello, TLSv1
***
pool-1-thread-1, WRITE: TLSv1 Handshake, length = 95
pool-1-thread-1, WRITE: SSLv2 client hello message, length = 131
pool-1-thread-1, READ: TLSv1 Handshake, length = 81
*** ServerHello, TLSv1
Cipher Suite: SSL_RSA_WITH_RC4_128_MD5
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: <empty>
***
%% Created:  [Session-4, SSL_RSA_WITH_RC4_128_MD5]
** SSL_RSA_WITH_RC4_128_MD5
pool-1-thread-1, READ: TLSv1 Handshake, length = 4313

*** ClientHello, TLSv1
Extension elliptic_curves, curve names: {secp256r1, sect163k1, sect163r2, secp192r1, secp224r1,sect233k1, sect23
 sect409k1, sect409r1, secp521r1, sect571k1, sect571r1, secp160k1, secp160r1, secp160r2,  sect163r1, secp192k1, se9k1,     secp256k1}
Extension ec_point_formats, formats: [uncompressed]
Extension server_name, server_name: [host_name: test.newdomain.com]
***
pool-5-thread-2, WRITE: TLSv1 Handshake, length = 181
pool-5-thread-2, READ: TLSv1 Handshake, length = 85
*** ServerHello, TLSv1
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA
Compression Method: 0
Extension server_name, server_name:
Extension renegotiation_info, renegotiated_connection: <empty>
***
%% Initialized:  [Session-1, TLS_RSA_WITH_AES_128_CBC_SHA]
** TLS_RSA_WITH_AES_128_CBC_SHA
pool-5-thread-2, READ: TLSv1 Handshake, length = 4312

    InputStream in = null;
    try {
        URL url = new URL("https://test.newdomain.com/myapp");
        URLConnection conn = url.openConnection();
        in = conn.getInputStream();
        System.out.println("OpenStream didn't fail!");
    } catch (IOException ex) {
        System.out.println(ex.getClass().getName()+ex.getMessage());
        System.out.println("Connection failed");
    } finally {
        try {
            if (in != null)
                in.close();
        } catch (IOException ex) {
        }
    }