Jump to content

Recommended Posts

Доброго времени суток!

Подскажите, каким образом можно максимально безболезненно (и можно ли вообще) понизить версию Администратора существующей сети с 3.2.9 до 3.1.1?

Пробовал просто "обновить" поверх установщиком, но потом не смог авторизоваться в УКЦ - сообщение "Не найден контейнер", хотя пароль администратора УКЦ вводил верный и путь к расположению контейнера был указан правильный.

Также очень интересует вопрос обновления Администратора с версии КС2 до КС3. Возможно ли такое в принципе? Если да, то как?

Share this post


Link to post
Share on other sites

Насколько я знаю downgrade версий ПО ViPNet не предусмотрен. Думаю только между смежными версиями возможно, а не 3.2 -> 3.1, потому что в 3.2 как минимум поменялся формат хранения контейнера, где хранится хэш пароля для входа в УКЦ. Любой upgrade версий без проблем и не надо смотреть по какому классу сертифицировано ПО.

Share this post


Link to post
Share on other sites

Насколько я знаю downgrade версий ПО ViPNet не предусмотрен. Думаю только между смежными версиями возможно, а не 3.2 -> 3.1, потому что в 3.2 как минимум поменялся формат хранения контейнера, где хранится хэш пароля для входа в УКЦ. Любой upgrade версий без проблем и не надо смотреть по какому классу сертифицировано ПО.

Т.е. переход с версии 3.2 КС2 на 3.2 КС3 вполне возможен? Как грамотно провести upgrade в таком случае?

Ситуация с отсутствием возможности downgrade-а меня совсем не радует. Сеть была развернута на версии 3.2, как на более новой, функциональной и с многочисленными исправлениями, несмотря на ее несертифицированность. А в данный момент (спустя полгода) потребовалось привести сеть в полное соответствие с нормативными документами ФСТЭК и ФСБ, т.е. необходимо применять сертифицированные версии продуктов. Вот я и ищу хоть какой-нибудь способ перейти с 3.2 на 3.1. Есть какие-нибудь соображения по этой ситуации? Также интересно, какие будут проблемы при использовании сертифицированных клиентов версии 3.1 с администратором версии 3.2?

Share this post


Link to post
Share on other sites

Поставь параллельный ЦУС 3.1 и не парься. Открывай его при аттестации, а работай на релизных версиях))

Насчет работы версий то без проблем: обязательно в новых версиях присутствует поддержка прежних.

Share this post


Link to post
Share on other sites

Поставь параллельный ЦУС 3.1 и не парься. Открывай его при аттестации, а работай на релизных версиях))

Насчет работы версий то без проблем: обязательно в новых версиях присутствует поддержка прежних.

Похоже, что так и придется сделать. ))

Про совместимость 3.1 клиентов с 3.2 администратором спросил потому, что периодически возникает проблема при первичной инициализации клиентов. Инициализация завершается ошибкой "Ошибка при выполнении инициализации. 58: Неправильный ключ..."

С 3.2 клиентами такой проблемы нет, но нам нужны сертифицированные клиенты 3.1. Грешу на администратор версии 3.2. В нем причина? Или на стороне клиента?

Share this post


Link to post
Share on other sites

Версии точно укажи (админ и клиент) и как время будет то попробую.

Share this post


Link to post
Share on other sites

Версии точно укажи (админ и клиент) и как время будет то попробую.

ViPNet Client KC3 3.1_(1.6238) и VipNet Administrator 3.2_(9.11065)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

У меня ситуация с ошибкой возникла на клиентской Windows 7 Pro x32. На сетевом узле было зарегистрировано два пользователя. Оба авторизуются по рутокену. Ключи шифрования и контейнер с сертификатом тоже на токене. Причем было два разных случая. В первом случае ошибка вываливалась при инициализации первого же пользователя. Во втором случае первый пользователь успешно инициализировался, а на втором - ошибка.

Как понять, кто виноват - Администратор версии 3.2 или Клиент версии 3.1?!

Share this post


Link to post
Share on other sites

Хоть и оффтоп, но спрошу здесь. Ставлю Администратора 3.2.9.11881 КС3 на чистую лицензионную Windows XP SP3. Разворачиваю с нуля сеть. ЦУС отработал без проблем, справочники в УКЦ передал. Запустил УКЦ, зарегистрировал в Мастере превичной инициализации УКЦ администратора УКЦ. А на заключительном шаге "Завершение инициализации УКЦ" на пункте "Создание администратора" выходит сообщение "Не удалось инициализировать Удостоверяющий и ключевой центр. Для работы приложения необходимо запустить заново". Повторный запуск ни к чему не приводит, та же ошибка.

Куда копать? Куда смотреть? С версией КС2 таких проблем ниразу не было.

Share this post


Link to post
Share on other sites

Хоть и оффтоп, но спрошу здесь. Ставлю Администратора 3.2.9.11881 КС3 на чистую лицензионную Windows XP SP3. Разворачиваю с нуля сеть. ЦУС отработал без проблем, справочники в УКЦ передал. Запустил УКЦ, зарегистрировал в Мастере превичной инициализации УКЦ администратора УКЦ. А на заключительном шаге "Завершение инициализации УКЦ" на пункте "Создание администратора" выходит сообщение "Не удалось инициализировать Удостоверяющий и ключевой центр. Для работы приложения необходимо запустить заново". Повторный запуск ни к чему не приводит, та же ошибка.

Куда копать? Куда смотреть? С версией КС2 таких проблем ниразу не было.

Я могу предположить, что проблема с базой данных УКЦ. УКЦ хранит базу данных либо в базе MS Access, либо на MS SQL Server, в зависимости от Вашего выбора. Может, неполадки с ODBC или с БД (если выбрали SQL Server).

Share this post


Link to post
Share on other sites

Я могу предположить, что проблема с базой данных УКЦ. УКЦ хранит базу данных либо в базе MS Access, либо на MS SQL Server, в зависимости от Вашего выбора. Может, неполадки с ODBC или с БД (если выбрали SQL Server).

Проблему решил. Дело было точно не в БД, т.к. ошибка вылетала еще на этапе формирования сертификата администратора УКЦ, а до конфигурации БД еще не дошло.

Оказалось, что неисправен Рутокен ЭЦП, который использовался в качестве аппаратного датчика случайных чисел. В УКЦ КС3 без таких никуда! ))

Share this post


Link to post
Share on other sites

Проблему решил. Дело было точно не в БД, т.к. ошибка вылетала еще на этапе формирования сертификата администратора УКЦ, а до конфигурации БД еще не дошло.

Оказалось, что неисправен Рутокен ЭЦП, который использовался в качестве аппаратного датчика случайных чисел. В УКЦ КС3 без таких никуда! ))

Так бы сразу и сказали, что ключ на токене. Проблема встречается такая даже не при несправном токене. Однажды мы пробовали развернуть УКЦ и всё замирало на заключительном шаге. Оказалось, что проблема была в 8-килобайтном токене, на который он уполно не мог записать ключи. Кстати, подскажите чем принципиально отличается поставка КС3 от КС2? Что там дополнительно вводится помимо АПМДЗ?

Share this post


Link to post
Share on other sites

Так бы сразу и сказали, что ключ на токене. Проблема встречается такая даже не при несправном токене. Однажды мы пробовали развернуть УКЦ и всё замирало на заключительном шаге. Оказалось, что проблема была в 8-килобайтном токене, на который он уполно не мог записать ключи. Кстати, подскажите чем принципиально отличается поставка КС3 от КС2? Что там дополнительно вводится помимо АПМДЗ?

Дело не в токене, как контейнере ключей администратора. При регистрации администрации было указано хранить его ключи в папке на диске. В реализации КС3 для генерации ключевой информации обязательно используется аппаратный датчик случайных чисел (Соболь, Аккорд, Рутокен ЭЦП и пр.) Отделаться биологическим (рулеткой) тут не получится! ))

По вопросу различий. Я знаю только то, КС3 отличается от КС2 как раз обязательным применением аппаратного ДСЧ. Других существенных отличий не замечал. Ну, в документации есть некоторые различия.

АПМДЗ обязателен для всего, что выше КС2 включительно. В КС2 он используется именной для доверенной загрузки и контроля целостности, а в КС3 еще и как аппаратный ДСЧ. В КС1 можно без АМПДЗ.

Share this post


Link to post
Share on other sites

Дело не в токене, как контейнере ключей администратора. При регистрации администрации было указано хранить его ключи в папке на диске. В реализации КС3 для генерации ключевой информации обязательно используется аппаратный датчик случайных чисел (Соболь, Аккорд, Рутокен ЭЦП и пр.) Отделаться биологическим (рулеткой) тут не получится! ))

По вопросу различий. Я знаю только то, КС3 отличается от КС2 как раз обязательным применением аппаратного ДСЧ. Других существенных отличий не замечал. Ну, в документации есть некоторые различия.

АПМДЗ обязателен для всего, что выше КС2 включительно. В КС2 он используется именной для доверенной загрузки и контроля целостности, а в КС3 еще и как аппаратный ДСЧ. В КС1 можно без АМПДЗ.

Спасибо за информацию. У меня был пробелы в представлении о классе КС3 и КА. Одним вопросом меньше. А то документации по данной тематике в открытом виде практически нет. А сталкиваться с КС3 пока не приходилось.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

By using this site, you agree to our Terms of Use.