Ключевое слово в защите информации
КЛЮЧЕВОЕ СЛОВО
в защите информации
Получить ГОСТ TLS-сертификат для домена (SSL-сертификат)
Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Icon
Error

Опции
К последнему сообщению К первому непрочитанному
Offline Helkor  
#1 Оставлено : 31 января 2012 г. 19:49:54(UTC)
Helkor

Статус: Участник

Группы: Участники
Зарегистрирован: 27.12.2011(UTC)
Сообщений: 11
Откуда: Санкт-Петербург

Настроена связка Tomcat+JCP+JTLS. Проверка подключения пользователя выключена.

Когда проверялось на подключение по одному IP адресу к сайту, был сделан ключ и сертификат, где в CN= стоял IP сервера. Ключ и сертификат были помещены в хранилища JCP. Подключаемся к сайту через https с указанием IP, все хорошо.

Хотим подключиться по доменному имени (причем пока речь идет только о внутреннем использовании, т.е. IP и доменные имена локальные) - ругается, мол подключаетесь к одному имени, а сертификат выдан на другое. Логично, правильно, нормально.

Делаем ключ и сертификат на доменное имя, ключ уже в хранилище, сертификат подкладываем. Перегружаем Tomcat. Пробуем зайти по доменному имени:
Вы попытались открыть hostname, однако фактически были направлены на сервер IP. Переадресации подобного рода происходят либо из-за ошибок конфигурации сервера, либо если кто-то пытается намеренно заставить вас посетить фальсифицированную копию страницы IP.

Пробуем со вторым сетевым интерфейсом, делаем ключ и сертификат с соответствующим CN. Тоже самое.

"Возня" с server.xml и прописыванием всех host и алиасов - не помогла. Зато получилось совсем здорово, уже в server.xml стоит defaulthost host и alias - только один, и это IP1. И при этом сервер отдает браузеру сертификат IP2, хотя заходим на сайт по IP1.
Даже уже имена контейнеров и имена сертификатов даны как CNы - ситуация та же.

В логе томката:

31.01.2012 0:56:16 ru.CryptoPro.ssl.i <init>
FINE: ClientHello sessionId:{}
31.01.2012 0:56:16 ru.CryptoPro.ssl.Q a
FINE: %% ClientHello, TLSv1; Cipher Suites: [Unknown 0x0:0x2f, Unknown 0x0:0x35, Unknown 0x0:0x5, Unknown 0x0:0xa, Unknown 0xc0:0x13, Unknown 0xc0:0x14, Unknown 0xc0:0x9, Unknown 0xc0:0xa, SSL3_CK_GVO_KB2, Unknown 0x0:0x38, Unknown 0x0:0x13, Unknown 0x0:0x4, TLS_CIPHER_94, TLS_CIPHER_2001]; Compression Methods: 0
31.01.2012 0:56:16 ru.CryptoPro.ssl.Q a
FINE: create new Session
31.01.2012 0:56:16 ru.CryptoPro.ssl.d a
FINE: %% getting aliases for Server
31.01.2012 0:56:16 ru.CryptoPro.ssl.d a
FINE: %% matching alias: IP2
31.01.2012 0:56:16 ru.CryptoPro.ssl.d a
FINE: %% matching alias: hostname
31.01.2012 0:56:16 ru.CryptoPro.ssl.d a
FINE: %% matching alias: IP1
31.01.2012 0:56:16 ru.CryptoPro.ssl.Q b
FINE: %%Choosen server alias: IP2
Offline Helkor  
#2 Оставлено : 2 февраля 2012 г. 19:09:05(UTC)
Helkor

Статус: Участник

Группы: Участники
Зарегистрирован: 27.12.2011(UTC)
Сообщений: 11
Откуда: Санкт-Петербург

Просто может тогда кто-нибудь подскажет. Это томкат неверно может передает для ru.CryptoPro.ssl имена, или все-таки ru.CryptoPro.ssl неверно может выбирать сертификат по CN? В первом случае забиваем, и делаем бинарную передачу через ngnix или прокси через apach. А во втором может тогда как-то это можно победить?
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
Guest (2)
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.