Jump to content

Recommended Posts

Добрый день.

1) В ЦУС формирую 2 АП, зарегистрированных в ПЗ Криптосервис. На каждом АП по одному пользователю, ТК которых связаны друг с другом, а также с Координатором.

Формирую дистрибутивы пользователей, переношу их на компы с установленным ПО VipNet CryptoService, провожу первичную инициализацию. Указываю контейнер закрытых ключей. Подписываю вордовский документ ЭЦП пользователя, переношу на второй АП, на котором также установлен криптосервис и проведена первичная инициализация.

Проблема в том, что второй пользователь видит в вордовском документе недействительную подпись. По идее в дистрибутиве должны храниться и корневой сертификат администратора, и СОС. Хотя их также копировал в явном виде, результат тот же.

В чем может быть причина?

2) Я правильно понимаю, что в корневом сертификате и в dst-файле хранятся как закрытый ключ пользователя, так и СОС и корневой сертификат.

3) В транспортных настройках для координатора задал ip-адрес. После нажатия на кнопку опросить в транспортном модуле пишет, что узел недоступен. Хотя VipNet Клиенты видят координатор.

Share this post


Link to post
Share on other sites

Добрый день.

1) В ЦУС формирую 2 АП, зарегистрированных в ПЗ Криптосервис. На каждом АП по одному пользователю, ТК которых связаны друг с другом, а также с Координатором.

Формирую дистрибутивы пользователей, переношу их на компы с установленным ПО VipNet CryptoService, провожу первичную инициализацию. Указываю контейнер закрытых ключей. Подписываю вордовский документ ЭЦП пользователя, переношу на второй АП, на котором также установлен криптосервис и проведена первичная инициализация.

Проблема в том, что второй пользователь видит в вордовском документе недействительную подпись. По идее в дистрибутиве должны храниться и корневой сертификат администратора, и СОС. Хотя их также копировал в явном виде, результат тот же.

В чем может быть причина?

2) Я правильно понимаю, что в корневом сертификате и в dst-файле хранятся как закрытый ключ пользователя, так и СОС и корневой сертификат.

3) В транспортных настройках для координатора задал ip-адрес. После нажатия на кнопку опросить в транспортном модуле пишет, что узел недоступен. Хотя VipNet Клиенты видят координатор.

1) Не установлены СОСы или корневой сертификат. Причину, по которой подпись недействительна нужно смотреть.

2)В DST файле хранятся корневой сертификат, СОСы и закрытый ключ подписи (если только он при формировании DST не записывался на отдельный носитель).

3)Чтобы сервис видел клиентов, необходимо чтобы в фильтрах открытой сети для данного компьютера были доступны порты 5000-5002 TCP.

Share this post


Link to post
Share on other sites

Спасибо за ответ.

Еще кое-что хотел бы уточнить.

1) По первому вопросу: После проведения первичной инициализации (закрытый ключ также в dst-файле) на обоих АП были запросы на установку корневых сертификатов, я их удовлетворил. А списки отозванных сертификатов каким образом устанавливать, если они хранятся в dst файле?

2) По поводу 3 вопроса, возможно, я несовсем правильно выразился. Необходимо проводить обновление СОС и сертификата пользователя. Какие настройки нужно произвести после первичной инициализации?

3) Вопрос в догонку(для проверки, правильно ли я делаю или что-то упускаю): чтобы пользователь мог корректно подписывать документы, в ЦУСе нужно АП зарегистрировать в ПЗ "Криптосервис". После этого для его ТК какие связи необходимо настроить? Только с Координатором или еще с кем-то(у меня связи с Администратором и координатором)?

Share this post


Link to post
Share on other sites

1) Подтверждать нужно только корневые сертификаты. СОСы ставятся автоматически

2)Обновление СОСов происходит по MFTP. Криптосервис работает без IPLir. Следовательно, это нешифрованный трафик. И необходимо добавить исключения в фильтры открытой сети координатора. Настройки нужно делать только на координаторе.

3)Достаточно связи только с координатором.

Share this post


Link to post
Share on other sites

Во, спасибо, как раз все у меня в голове уложилось по полочкам.

Еще одна проблема: я через RegPoint создал двух пользователей и для них сертификаты, разослал контейнеры на компьютеры с VipNet CSP, установил корневой сертификат и СОС на каждый ПК. Подписывает/проверяет подпись нормально.

Проделал примерно те же самые операции для VipNet CryptoService, установил корневой сертификат, на всякий случай и СОС. Документы подписываются, но на втором ПК при проверке подписи пишет, что она недействительна. Хотя сертификаты актуальны.

Сравнив сертификаты в CSP и CryptoService обнаружил, что в сведения о сертификате:

1) для CSP сертификат:

- Подтверждает удаленному компьютеру идентификацию вашего компьютера;

- Защищает сообщения электронной почты.

2) для CryptoService только одна задача:

- Защищает сообщения электронной почты.

Я думаю, что, скорее всего, из-за этого подпись в документе считается недействительной.

Собственно вопрос, почему в сертификате из dst-файла не содержится задачи "Подтверждает удаленному компьютеру идентификацию вашего компьютера"?

В ЦУС я указал для ТК CryptoService только ПЗ "Криптосервис", хотя других ПЗ и не должно быть зарегистрированно.

Share this post


Link to post
Share on other sites

Данный вариант использования подписи "подтверждает .... идентификацию..." является обязательным для организации TLS-соединения (насколько я помню). Таким образом, проблема связана не с этим. В Вашем случае стоит проверить корректность установки СОС (и актуальности).

Share this post


Link to post
Share on other sites

Криптосервис работает без IPLir. Следовательно, это нешифрованный трафик. И необходимо добавить исключения в фильтры открытой сети координатора. Настройки нужно делать только на координаторе.

Исключения в фильтрах открытой сети делаются в МЭ координатора, разделе [forward]?

Если так, то трафик откуда куда нужно разрешить? Я создал правило, разрешающее трафик по всем протоколам с АП с криптосервисом до координатора (интерфейс открытой сети) и наоборот от координатора до АП. Интерфейс координатора не пингуется. Или я что-то неправильно понимаю?

Share this post


Link to post
Share on other sites

Исключения в фильтрах открытой сети делаются в МЭ координатора, разделе [forward]?

Если так, то трафик откуда куда нужно разрешить? Я создал правило, разрешающее трафик по всем протоколам с АП с криптосервисом до координатора (интерфейс открытой сети) и наоборот от координатора до АП. Интерфейс координатора не пингуется. Или я что-то неправильно понимаю?

Нужно сделать входящие соединения на координатор с узла криптосервиса по портам TCP 5000-5002. И наоборот - с координатора на эти порты узла криптосервиса (иногда координатор сам пытается установить соединение). У Вас, как я понимаю, linux координатор?

Share this post


Link to post
Share on other sites

Нужно сделать входящие соединения на координатор с узла криптосервиса по портам TCP 5000-5002. И наоборот - с координатора на эти порты узла криптосервиса (иногда координатор сам пытается установить соединение). У Вас, как я понимаю, linux координатор?

Да, Linux координатор HW1000. Попробовал в файерволе прописать данные правила, не помогло.

Криптосервис без ПЗ "Защита трафика", мб с этим связано?

Share this post


Link to post
Share on other sites

Да, Linux координатор HW1000. Попробовал в файерволе прописать данные правила, не помогло.

Криптосервис без ПЗ "Защита трафика", мб с этим связано?

Криптосервис и не должен, насколько я понмю, быть в задаче защита трафика, поскольку её там нет. А в журнале блокированных пакетов не видно блокировок на данный IP-адрес

Share this post


Link to post
Share on other sites

Криптосервис и не должен, насколько я понмю, быть в задаче защита трафика, поскольку её там нет. А в журнале блокированных пакетов не видно блокировок на данный IP-адрес

Единственная запись в журнале координатора.

Поскольку трафик с данного АП не шифруется, нужно ли помимо разрешающего правила в файерволе прописывать еще доп. правила, например, создавать полутуннель?

39a2a901884b.jpg

Share this post


Link to post
Share on other sites

Единственная запись в журнале координатора.

Поскольку трафик с данного АП не шифруется, нужно ли помимо разрешающего правила в файерволе прописывать еще доп. правила, например, создавать полутуннель?

39a2a901884b.jpg

Нет - туннель не обязательно делать. Достаточно прописать разрешающее правило. Туннель всё равно не шифруется, так как на том ПК нет криптографии. В журнале записей маловато. Вы как ограничивали выводимые записи? Если пакет приходит, он должен либо блокироваться, либо пропускаться.

Share this post


Link to post
Share on other sites

Нет - туннель не обязательно делать. Достаточно прописать разрешающее правило. Туннель всё равно не шифруется, так как на том ПК нет криптографии. В журнале записей маловато. Вы как ограничивали выводимые записи? Если пакет приходит, он должен либо блокироваться, либо пропускаться.

Извиняюсь, напутал немного с айпишником. Завтра напишу то, что нужно, заодно скажу ограничения выводимых записей в журнале.

Если не сложно, посмотрите, пожалуйста, еще одну тему: http://www.infotecs.ru/forum/index.php?showtopic=7448

Share this post


Link to post
Share on other sites

Журнал пакетов:

d7a6d192c182.jpg

Все пакеты, направляемые на интерфейс координатора, удаляются. Во всех остальных фильтрах пакетов нет.

Share this post


Link to post
Share on other sites

Все пакеты, направляемые на интерфейс координатора, удаляются. Во всех остальных фильтрах пакетов нет.

Журнал пишет, что пакет заблокирован. Нужно добавить разрешающее правило.

Share this post


Link to post
Share on other sites

Журнал пишет, что пакет заблокирован. Нужно добавить разрешающее правило.

В разделе [forward] межсетевого экрана уже добавлял правила разрешающие входящий трафик с криптосервиса на координатор и наоборот по портам 5000-5002.

Share this post


Link to post
Share on other sites

В разделе [forward] межсетевого экрана уже добавлял правила разрешающие входящий трафик с криптосервиса на координатор и наоборот по портам 5000-5002.

Видимо, нужно посмотреть с порядком правил - нет ли ранее запрещающего. 30-ое событие - это блокировка фильтрами открытой сети. А добавлять правило нужно не в forward (транзит), а в local.

Share this post


Link to post
Share on other sites

Спасибо, все прекрасно работает.

Последний вопрос в этой теме: "Будут ли конфликтовать на одной машине КриптоПро и VipNet CryptoService? Если да, то как избежать конфликта?"

Share this post


Link to post
Share on other sites

Спасибо, все прекрасно работает.

Последний вопрос в этой теме: "Будут ли конфликтовать на одной машине КриптоПро и VipNet CryptoService? Если да, то как избежать конфликта?"

Да, есть между ними некие трения. Вроде бы, насколько я помню, сначала стоит ставить криптопро, а потом - випнет. Тогда проблем меньше. Если наоборот - возможны трудности. Хотя, они меняются от установки к установке.

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.