Почему Java 6 получает цепочку сертификатов SSL, отличную от Java 7?

1

Мы переконфигурировали один из наших серверов, чтобы изменить имя хоста одного из его виртуальных хостов.

Конфигурация нашего сервера:

<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) {
        }
    }

Благодарю!

  • 1
    Разница, несомненно, заключается в том, что java7 (Https) URLConn, как и (все? Основные?) Браузеры, отправляет индикацию имени сервера (SNI), а java6 - нет, как подтверждает ваш отладочный вывод. Серверу named-vhost требуется SNI для указания желаемого хоста и, следовательно, сертификата, а без SNI необходимо выполнить некоторые настройки по умолчанию, что, по-видимому, неправильно в вашем случае, но я не знаю достаточно httpd, чтобы точно сказать, где искать.
  • 0
    Большое спасибо за ваш комментарий Дэйв. Мы что-то думали в этом направлении, но я не знал о SNI. По крайней мере, мне сейчас есть что исследовать. Еще раз спасибо!
Теги:
ssl

1 ответ

2
Лучший ответ

Отвечая на мой собственный вопрос на основе ввода, предоставленного date_thompson_085.

Проблема в том, что запрос всегда отправляется с использованием IP-адреса, а имя хоста содержится в заголовках http. Однако с SSL эта информация об имени хоста зашифровывается. Поэтому, когда SSL-квитирование происходит, он еще не знает имя хоста. Из-за этого он не знает, к какому виртуальному хосту должен идти запрос, и возвращает первые (или по умолчанию) сертификаты, в нашем случае olddomain.com, который является неправильным.

Причина, по которой браузеры и java7 не затрагиваются, заключается в том, что они отправляют идентификацию имени сервера (SNI) как часть информации SSL. Таким образом, apache знает, какой виртуальный хост должен использовать, прежде чем начинать SSL-квитирование и возвращает соответствующий сертификат. Java 6 не поддерживает SNI.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню