Деловая почта ругается на отсутствующий CRL

[zv0r]

Добрый день.

Имеется межсетвое взаимодействие. Некоторые абонентские пункты моей сети и АП доверенной сети обмениваются сообщениями через Деловую почту. Когда сотрудникам в моей сети приходит сообщение, Деловая почта ругается на подпись, а именно на то, что неизвестно, является ли сертификат отозванным.

Проверил УКЦ, все списки отозванных сертификатов из доверенной сети действующие. На всякий случай загрузил их вручную с e-trust.gosuslugi.ru и попытался загрузить, но УКЦ лишь сообщил, что список уже загружен.

В разделе "Администрирование" в УКЦ абонентские пункты моей сети, участвующие в обмене электронными документами, добавлены в список "Получатели списков аннулированных сертификатов". Сам УКЦ всегда запущен в автоматическом режиме.

Может, я что-то упустил?

Конфигурация клиентов: Win7, client и ДП 4.3.2.46794.

Конфигурация администратора: Win 8.1, УКЦ 4.6.1.37636, ЦУС 4.6.1.3861.

 

[Заикающийся]

А Касперский есть на компьютере, а именно KES 10.x.x.x?

[zv0r]

Нет

[R.Sheyn]

Попробуйте создать ключи пользователей еще раз и разослать, иногда помогает.

[zv0r]

8 часов назад, R.Sheyn сказал:

Попробуйте создать ключи пользователей еще раз и разослать, иногда помогает.

Попробовал первым делом. К сожалению, не помогло...

[Заикающийся]

Сформируй для всей сети ключи заново.

[zv0r]

35 минут назад, Заикающийся сказал:

Сформируй для всей сети ключи заново.

Для всех пользователей и всех узлов. Отправить CRL в ЦУС для всех узлов тоже делал. Результат нулевой.

[zv0r]

Попытался еще установить CRL вручную встроенными средствами windows. Опять мимо.

[R.Sheyn]

А точно ставите crl того УЦ, на котором выпущены сертификаты отправителей?

[zv0r]

15 минут назад, R.Sheyn сказал:

А точно ставите crl того УЦ, на котором выпущены сертификаты отправителей?

Абсолютно.

[Apostol]

Есть ли возможность узнать версию УКЦ из смежной сети? по какому ГОСТ выпущены сертификаты на узлах их сети, на письма которых появляется ошибка?

[zv0r]

Там не очень приятные люди с той стороны (если они это читают, то наверняка меня узнают, так что адресую им великую классическую цитату Линуса Торвальдса для компании nvidia), поэтому про версию УКЦ, к сожалению, ничего не могу сказать. Сертификаты пока что встречаются и по 2001 и по 2012 ГОСТу.

[Vintik]

В 06.02.2019 в 21:38, zv0r сказал:

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

Только в вашей сети это? С той сторону нет проблем? И у вас сколько таких АП с 10-к или сотни и тысячи (чтоб сравнить у всех ли так или у одного двух, тогда бывает надо там клиента переставить)?

Понятно что вы можете у себя отключить эти проверки, но хочется чтоб было как требуется и потому разобраться.

Т.к. вы уже видно ключи рассылали (с ними за одно с CRL шлюстя, обычно тоже так приходится, когда отдельно CRL не помогает), то ещё как вариант для проверки можно в ручную их на клиента подкинуть и посмотреть как Випнет Клиент его пережует. Ещё интересно это именно только с одного места не проходит проверку, все остальные другие проверяет? И на УКЦ я заметил вы уже всё проверили и там свежие и отзывы и цепочка и т.п. потому УКЦ не трогаем. Потом после уточнения что там на клиенте и как получится, можно продолжить дальше.

[zv0r]

2 часа назад, Vintik сказал:

Только в вашей сети это? С той сторону нет проблем? И у вас сколько таких АП с 10-к или сотни и тысячи (чтоб сравнить у всех ли так или у одного двух, тогда бывает надо там клиента переставить)?

Понятно что вы можете у себя отключить эти проверки, но хочется чтоб было как требуется и потому разобраться.

Т.к. вы уже видно ключи рассылали (с ними за одно с CRL шлюстя, обычно тоже так приходится, когда отдельно CRL не помогает), то ещё как вариант для проверки можно в ручную их на клиента подкинуть и посмотреть как Випнет Клиент его пережует. Ещё интересно это именно только с одного места не проходит проверку, все остальные другие проверяет? И на УКЦ я заметил вы уже всё проверили и там свежие и отзывы и цепочка и т.п. потому УКЦ не трогаем. Потом после уточнения что там на клиенте и как получится, можно продолжить дальше.

Судя по отсутствию жалоб с другой стороны, проблема только у нас. 

С нашей стороны 6 АП, с другой около сотни.

Если переразвернуть dst, то все становится хорошо. Но не бегать же каждый месяц сотрудникам раскатывать новый dst... Если я неправильно понял "вручную подкинуть ключи на клиента", то я не знаю, как это еще делается.

[Vintik]

Если новая ДСТшка всё исправляет (на время) то это 100% Клиент косячит, тоже такое было, так и не понял в чём проблема. Тогда было много обновлений с 3 на 4 не удаляя, потому я на это подозревал и потом (благо тоже не больше 10-ка таких) взял всё снёс и под ноль поставил. Проблемы вроде ушла, но т.к. там очень редко пользуются ДП и обычной без всякого автопроцесса, то видно даже не обращают внимание и я недавно заметил что вроде снова перестал проверять, но совсем мне до этого и пока не стал рассматривать.

По каким то причинам подозреваю там где то не хватает "хитрых" прав или это каспер шалит и не даёт, но это точно проблема раб места.

Как попробовать в ручную я написал так (сильно не судите, пишу как умею):

Если САС не принимаются на автомате, то можно (нужно) попробовать как они принимаются в ручную.

1. Из УКЦ администратор выгружает в файл список CRL, формат будет "apn_***x.ke"
2. Завершить работу Клиента и деловой почты (выйти из них полностью).
3. Полученный файл с расширением *.ke скопировать в папку "key", откуда у вас запускается клиент, на пример может быть путь:
C:\Program Files (x86)\InfoTeCS\ViPNet Client\CCC\key
4. Запустить Випнет Клиент и наблюдать чтоб скопированный файл "исчез", это значит он принялся в обработку.
5. Проверить повторно письма где была причина не верного сертификата, если проблема остаётся то сделать 2-3 скрина сертификата, если есть возможность то переправить сертификат который не проходит проверку.
Эти данные потребуется для передачи их администраторам сети, откуда они поступают.
6. Дополнительно - вернуться на каталог выше "CCC" и проверить, чтоб в нём были только "папки".
Если там есть какие то файлы и они "не пропадают" то удалить их (можно переместить для диагностики),
там файлов быть не должно т.к. они должны уходить в обработку, если у вас Випнет Клиент настроен
на автоматическую обработку. Если он на ручном режиме приёма обновлений ключей и справочников,
то обработать всё и в итоге файлов там не должно оставаться. 

[zv0r]

33 минуты назад, Vintik сказал:

Если новая ДСТшка всё исправляет (на время) то это 100% Клиент косячит, тоже такое было, так и не понял в чём проблема. Тогда было много обновлений с 3 на 4 не удаляя, потому я на это подозревал и потом (благо тоже не больше 10-ка таких) взял всё снёс и под ноль поставил. Проблемы вроде ушла, но т.к. там очень редко пользуются ДП и обычной без всякого автопроцесса, то видно даже не обращают внимание и я недавно заметил что вроде снова перестал проверять, но совсем мне до этого и пока не стал рассматривать.

По каким то причинам подозреваю там где то не хватает "хитрых" прав или это каспер шалит и не даёт, но это точно проблема раб места.

Как попробовать в ручную я написал так (сильно не судите, пишу как умею):

Если САС не принимаются на автомате, то можно (нужно) попробовать как они принимаются в ручную.

1. Из УКЦ администратор выгружает в файл список CRL, формат будет "apn_***x.ke"
2. Завершить работу Клиента и деловой почты (выйти из них полностью).
3. Полученный файл с расширением *.ke скопировать в папку "key", откуда у вас запускается клиент, на пример может быть путь:
C:\Program Files (x86)\InfoTeCS\ViPNet Client\CCC\key
4. Запустить Випнет Клиент и наблюдать чтоб скопированный файл "исчез", это значит он принялся в обработку.
5. Проверить повторно письма где была причина не верного сертификата, если проблема остаётся то сделать 2-3 скрина сертификата, если есть возможность то переправить сертификат который не проходит проверку.
Эти данные потребуется для передачи их администраторам сети, откуда они поступают.
6. Дополнительно - вернуться на каталог выше "CCC" и проверить, чтоб в нём были только "папки".
Если там есть какие то файлы и они "не пропадают" то удалить их (можно переместить для диагностики),
там файлов быть не должно т.к. они должны уходить в обработку, если у вас Випнет Клиент настроен
на автоматическую обработку. Если он на ручном режиме приёма обновлений ключей и справочников,
то обработать всё и в итоге файлов там не должно оставаться. 

Подсунуть вручную файлы *.ke помогло. Видимо, действительно, стоит попробовать переустановить клиент. Хорошо, что их немного. Спасибо за инструкцию

[Vintik]

Рекомендую для проверки хотя бы 2-шт поставить другой сборки, чтоб исключить вариант что именно в одной из сборок проблемы.

Как вы сами убедились, отдельно он нормально подкидывает, а когда получает тоже самое из ЦУС, то по не понятным причинам не делает это как надо.

Или как крайний вариант, примерно рассчитать когда будет пропадать и тем же автопроцесенгом, настроить чтоб до этого дня "Х" всем отправлять и там автоматом будут они подкладываться. 

[zv0r]

6 часов назад, Vintik сказал:

Рекомендую для проверки хотя бы 2-шт поставить другой сборки, чтоб исключить вариант что именно в одной из сборок проблемы.

Как вы сами убедились, отдельно он нормально подкидывает, а когда получает тоже самое из ЦУС, то по не понятным причинам не делает это как надо.

Или как крайний вариант, примерно рассчитать когда будет пропадать и тем же автопроцесенгом, настроить чтоб до этого дня "Х" всем отправлять и там автоматом будут они подкладываться. 

Пожалуй, так и сделаю. Спасибо еще раз.

[Vintik]

В 20.02.2019 в 10:51, zv0r сказал:

Пожалуй, так и сделаю. Спасибо еще раз.

Пожалуйста!  ;-)

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