Мы переконфигурировали один из наших серверов, чтобы изменить имя хоста одного из его виртуальных хостов.
Конфигурация нашего сервера:
<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>
чтобы:
<VirtualHost *:443>
ServerName test.newdomain.com
ServerAlias test.olddomain.com
SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile "D:/Security/wildcard/NEWDOMAIN.COM.crt"
SSLCertificateKeyFile "D:/Security/wildcard/NEWDOMAIN.COM.key"
SSLCertificateChainFile "D:/Security/wildcard/CertChain.crt"
...
</VirtualHost>
С любым веб-браузером мы можем получить доступ к сайту просто отлично, у нас нет никаких проблем с сертификатами. Однако когда я пытаюсь получить доступ к URL-адресу с Java 6, и я получаю эту ошибку:
java.security.cert.CertificateException: No subject alternative DNS name matching test.newdomain.com found
Я попытался запустить java с параметром -Djavax.net.debug = SSL и странно java получает сертификат olddomain:
*** 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]
Однако, если я заменил java6 на java7. Он правильно читает соответствующий сертификат, и я могу получить доступ к 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
java7 рукопожатие:
*** 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
Может кто-нибудь объяснить, почему java6 может вести себя иначе, чем java7 и веб-браузеры, и как это исправить?
В случае, если это имеет значение, это код, который я использую для проверки возможности подключения. Ничего особенного:
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) {
}
}
Благодарю!
Отвечая на мой собственный вопрос на основе ввода, предоставленного date_thompson_085.
Проблема в том, что запрос всегда отправляется с использованием IP-адреса, а имя хоста содержится в заголовках http. Однако с SSL эта информация об имени хоста зашифровывается. Поэтому, когда SSL-квитирование происходит, он еще не знает имя хоста. Из-за этого он не знает, к какому виртуальному хосту должен идти запрос, и возвращает первые (или по умолчанию) сертификаты, в нашем случае olddomain.com, который является неправильным.
Причина, по которой браузеры и java7 не затрагиваются, заключается в том, что они отправляют идентификацию имени сервера (SNI) как часть информации SSL. Таким образом, apache знает, какой виртуальный хост должен использовать, прежде чем начинать SSL-квитирование и возвращает соответствующий сертификат. Java 6 не поддерживает SNI.