diadocsdk-1c-docs
diadocsdk-1c-docs copied to clipboard
diadoc
Непонятные проблемы с используемыми ЭП после обновления на 5.54.0.1016
Добрый день.
Общая информация для упрощения «разбора полётов»: Организация: «ДНС Ритейл» ИНН: 2540167061 КПП: 254301001 ID организации: [email protected] ID участника ЭДО: 2BM-2540167061-254001001-201312151140099321090
Мы работаем с Диадок с использованием компонент АПИ для 1С https://diadocsdk-1c.readthedocs.io/ru/latest/index.html Текущая используемая версия: COM x64 5.54.0.1016
После перехода на версию 5.54.0.1016 (см. https://github.com/diadoc/diadocsdk-1c-docs/issues/1128) заметили, что новая механика работы SetPin() более жестко проводит проверки сертификатов в реестре сервера.
И по некоторым сертификатам у нас стали выпадать ошибки, с которыми мы не знаем, что делать и откуда они вообще взялись, т.к. сертификаты устанавливаются одним и тем же образом автоматически.
Далее приведу эти ошибки.
Ошибка вида 1
Отражается в логах так:
Ошибка при вызове метода контекста (SetPin): Произошла исключительная ситуация (CertificateInfo.SetPin): WIN32[0x80090016]CryptAcquireCertificatePrivateKey Keyset does not exist]
При этом проверено, что:
- На контейнер ЭП на сервере установлен пароль.
- Мы в коде в SetPin() точно передаем именно этот пароль.
Ошибка вида 2
Отражается в логах так:
Ошибка при вызове метода контекста (SetPin): Произошла исключительная ситуация (CertificateInfo.SetPin): CRYPTO[0x0000002F] gui authentication requested in silent mode]
Ситуация, как и в варианте №1:
Проверено, что:
- На контейнер ЭП на сервере установлен пароль.
- Мы в коде в SetPin() точно передаем именно этот пароль.
Важно
Что интересно, при работе через компоненту версии 5.52.4.989 таких ошибок с этими ЭП не наблюдалось.
Может быть вы сможете объяснить, в чем проблемы и можно ли их починить каким-то образом не прибегая к тому, чтобы полностью удалить сертификаты с сервера и затем поставить их на него заново.
Спасибо.
Добрый день
Нужна дополнительная информация:
- Как именно выполняется задание пинов у множества сертов: это в один поток или несколько, и если попробовать задать пины только у проблемного серта отдельно, то будет ли возникать та же ошибка?
- Если падают именно определенные серты, независимо от того, как вызывать
SetPin(), то есть ли возможность проверить их работу на версии 5.53.1-5.53.4 (т.е. до фикса с появлением окна если пин не задан, но после 5.53.1)?
Добрый день.
Первое
Потоков несколько. Т.е. условно примерно в одно и то же время в двух соседних потоках может сработать SetPin по разным сертификатам с разными паролями. НО! При этом проблема не плавающая, а стабильно 100% возникающая только по нескольким заданным сертификатам.
Если более конкретно, то после перехода на 5.54.0.1016 у нас ошибка №1 стабильно возникает только по 2-м установленным сертификатам и ошибка №2 также стабильно возникает только по 2-м другим установленным сертификатам.
Т.е., очень похоже, что дело всё-таки не в многопоточности.
Второе
К сожалению, всё это происходит на проде и мы не имеем возможности отключить пароли на установленных сертификатах.
По той же причине мы не сможем проверить поведение на более ранних версиях, т.к. пароли снять не сможем, а всплывающие окна ввода пароля на сервере нам все ЭДО просто грохнут.
Третье
Мы в ближайшее время попробуем посмотреть, что и как будет с этими ЭП, если их полностью удалить с сервера и попросить заново установить с обновленными паролями.
Быть может, это просто какой-то локальный "глюк", который при этом самоустраниться. По итогу опыта - сообщим пропала проблема или нет.
Четвертое
Очень бы хотелось и было бы здорово увидеть какую-то информацию от вас о том, что вообще означают эти две ошибки:
- WIN32[0x80090016]CryptAcquireCertificatePrivateKey Keyset does not exist]
- CRYPTO[0x0000002F] gui authentication requested in silent mode]
В каких случаях и почему они могут возникать?
Это, возможно, помогло бы нам в устранении проблемы с нашей стороны, если это вообще возможно.
А то поиск по интернету выдает либо эту же страницу, либо какую-то ерунду с форумов КриптоПро, датированную чуть ли не 2014 годом. И то, что там написано, вообще ничего и ни о чем не объясняет.
Внутри метода SetPin происходит запроса дескриптора контейнера закрытых ключей, и по нему устанавливается пин. Затем операция с закрытым ключом - это проверка для правильности установки пароля, ее добавили в рамках тикета
Ошибка CryptAcquireCertificatePrivateKey Keyset does not exist] вылетает при попытке запросить дескриптор контейнера закрытых ключей. Наиболее вероятная причина - пин не задан
Ошибка gui authentication requested in silent mode внутри метода SetPin вылетает, если не был задан верный пароль, хотя функции задания пина отработали успешно. По сути это тестовое выполнение операции с закрытым ключом, только вместо окна КриптоПро выбрасывается это исключение. Скорее всего, эта ошибка указывает на неверный пин
Спасибо за разъяснение по поводу ошибок.
Правда есть такой момент, что по всем 4-м сертификатам (2 с одной ошибкой и 2 с другой) несколько раз проводили проверку и на 100% уверены в том, что:
- Пароли на все сертификаты установлены.
- Мы передаем именно те пароли, что установлены на сертификаты.
Собственно, я это ранее в первоначальном сообщении уже указывал.
Вопрос-гипотеза: А есть ли какие-то символы, которых в пароле быть не должно? В том смысле, что не надо ли какие-то символы при формировании пароля исключать, т.к., например, в КриптоПро при установке пароля на контейнер можно что-то "эдакое" ввести, что потом при указании этого "эдакого" в SetPin() приведет к ошибке, т.к. какой-то "странный" символ не будет передан верно?
А может быть есть какие-то ограничения (или рекомендации) по поводу кодировки символов, передаваемых в SetPin? Может это быть проблемой различия кодировок для пароля, заданного на сертификат и пароля, передаваемого в SetPin()?
В любом случае - мы попробуем все эти сертификаты удалить и установить заново. Возможно, что что-то "проглючило".
О результате отпишусь.
Добрый день.
К сожалению у нас не очень получилось проверить ранее описанные проблемы с ЭП на сервере. Сказалась инерция владельцев ЭП.
Мы на этой неделе повторно запустили рассылку и опросы с просьбой к пользователям с проблемными сертификатами удалить их и установить заново. Постараемся в этот раз "продавить" всех и посмотреть, что же будет в итоге.
Возможно, что-то полечится, т.к. один пользователь все-таки что-то сделал - и по одному из сертификатов ошибка "CRYPTO[0x0000002F] gui authentication requested in silent mode" на сервере исчезла. Теперь подключение по нему происходит без проблем.
Но мы не знаем ЧТО ИМЕННО он сделал! Сейчас в новой переписке, в числе прочего, попробуем это узнать. Возможно, действительно просто он единственный, кто нас послушал и переустановил сертификат на сервере. Но пока это только предположение. Выясняем.
Однако, в процессе разбора этих проблем мы натолкнулись на новую проблему
Крайне неприятную.
И я бы сказал, что даже более значимую, чем ранее описанные проблемы с ЭП на сервере!
Предполагаем, что это некая вариация проблем, о которых я ранее писал в (https://github.com/diadoc/diadocsdk-1c-docs/issues/1107).
Но не для ЭП на сервере, а для ЭП, которые пользователи используют локально, по месту работы. Т.е., например, тогда, когда для работы с ЭДО пользователь вставляет флешку / токен в свой компьютер и выполняет все действия в ЭДО на этом компьютере. На клиенте 1С. Без какого-либо обращения к серверу 1С.
Суть проблемы:
Важно! При локальной работе пользователя мы не знаем пароль к его ЭП. И никак с этим паролем не работаем. Т.е. SetPin() не используем. Пользователь вводит пароль к своей ЭП через всплывающее окно КриптоПро.
Рассмотрим на примере подписания входящего документа.
Как это работает в версии 5.52.4.989:
- Пользователь хочет подписать документ.
- Вставляет флешку с ЭП в свой компьютер.
- Нажимает в 1С в документе ЭДО на кнопку "Подписать".
- Мы подключаем компоненту AddIn x64 5.52.4.989
- Мы получаем список доступных сертификатов.
- Пользователь выбирает из них свой со вставленной флешки.
- Мы выполняем подключение по сертификату.
- В этот момент, т.к. на сертификат установлен пароль - выскакивает окно КриптоПро для ввода пароля. (Т.е. мы с паролем вообще дела не имеем и никак с ним в коде в этой ситуации не работаем!).
- Пользователь вводит пароль.
- Мы подключаем по сертификату.
- Мы выполняем код, формирующий данные для подписания документа: (Получаем объект ReplySendTask2 через CreateReplySendTask2("AcceptDocument"), заполняем его и т.д.).
- После заполнения всех необходимых данных мы вызываем метод Send() для заполненного объекта ReplySendTask2.
- Вот тут почему-то (?!!!) снова выпрыгивает окно КриптоПро для ввода пароля сертификата. (Хотя мы его только что вводили перед подключением по этому сертификату!)
- Пользователь вводит пароль повторно! (скорее всего думая "Какого черта второй раз-то?!")
- Выполняется подписание документа и документ по итогу становиться подписанным.
Как это работает в версиях начиная с 5.53.1.1004 и далее:
Мы только что проверяли это на нашей текущей версии 5.54.0.1016:
- Пользователь хочет подписать документ.
- Вставляет флешку с ЭП в свой компьютер.
- Нажимает в 1С в документе ЭДО на кнопку "Подписать".
- Мы подключаем компоненту AddIn x64 5.54.0.1016
- Мы получаем список доступных сертификатов.
- Пользователь выбирает из них свой со вставленной флешки.
- Мы выполняем подключение по сертификату.
- В этот момент, т.к. на сертификат установлен пароль - выскакивает окно КриптоПро для ввода пароля. (Т.е. мы с паролем вообще дела не имеем и никак с ним в коде в этой ситуации не работаем!).
- Пользователь вводит пароль.
- Мы подключаем по сертификату.
- Мы выполняем код, формирующий данные для подписания документа: (Получаем объект ReplySendTask2 через CreateReplySendTask2("AcceptDocument"), заполняем его и т.д.).
- После заполнения всех необходимых данных мы вызываем метод Send() для заполненного объекта ReplySendTask2.
- !!!
- И вот тут почему-то (?!!!) НЕ выпрыгивает окошко КриптоПро для ввода пароля!
- !!! А вместо этого, похоже, ваш код компоненты просто начинает работать далее. Без введенного пароля! И выпадает в исключение, возвращая нам ошибку: Произошла исключительная ситуация (ReplySendTask2.Send): CRYPTO[0x0000002F] gui authentication requested in silent mode
Практически все такие ошибки, что мы нашли и разобрали, связаны именно с операцией подписания документа. Но на нее попадали и в при попытке отправки пакета документов. И при отказе от подписания.
Т.е. проблема не связана именно с операцией подписания. Мы, скорее, предполагаем, что она связана с операциями, в которых в ЭДО явным образом задействуется сертификат ЭП.
Общее впечатление
Такое ощущение, что прорабатывая проблему в топике (https://github.com/diadoc/diadocsdk-1c-docs/issues/1107), вы починили обработку паролей для ситуаций подключения компоненты, связанные с использованием SetPin().
Но не починили ситуации, которые почему-то иногда возникают, когда SetPin() не используется. Например, при повторном запросе пароля при запуске ReplySendTask2.Send().
Причем вообще не понятно зачем происходит что-то, что КриптоПро спрашивает пароль еще раз! Его же только что, буквально пару секунд назад, вводили при подключении по ЭП!
По идее было бы самым правильным сделать как-то так, что после подключения по ЭП уже не надо было бы тут же при вызове ReplySendTask2.Send() еще раз вводить тот же самый пароль!
Тогда и проблемы бы скорее всего не было бы.
Замечание №1
Такое поведение (с повторным запросом пароля) происходит только на клиенте 1С! На сервере в фоновых мы такой проблемы не замечали.
Возможно, потому, что на сервере мы пароли задаем явно, используя SetPin(). А при локальной работе пользователей по месту они вводят пароль через всплывающее окно КриптоПро.
Замечание №2. ВАЖНО!
Самое плохое в том, что это не 100% воспроизводимая проблема!
Т.е. такая ошибка при вызове ReplySendTask2.Send() получается не всегда.
У нас есть пользователи, у которых всё работает без проблем. Но есть и пользователи, у которых возникает такая ошибка.
Скорее всего это как-то связано с нововведениями в новых версиях компоненты, начиная с версии 5.53.1.1004 и далее. И, возможно, это как-то пересекается с версиями КриптоПро, версиями и настройками операционной системы и т.п. Мы тут можем только гадать.
Важно то, что в версиях ранее 5.53.1.1004 этой проблемы 100% нет!
И важно то, что мы с нашей стороны никак не можем повлиять на попадание в эту ошибку и, по факту, невозможность некоторых пользователей работать с ЭДО.
Итого
Огромная просьба разобраться с проблемой.
И сделать так, чтобы при работе на клиенте, как в версиях ранее 5.53.1.1004 не было ошибки. И просто нормально всплывало окно для повторного ввода пароля. Если он не задан через SetPIn()! И не всплывало бы - если пароль через SetPin() уже задан.
Либо, что и удобнее, и логичнее - чтобы повторной попытки запроса пароля после того, как его только что ввели при подключении к ЭДО - просто не было бы!
Сейчас это для нас ОЧЕНЬ большая проблема, т.к. по факту у нас некоторые пользователи нормально работать с ЭДО из 1С не могут, т.к. попадают на такую ошибку.
И мы ее явным образом никак не контролируем и поправить не можем. Это явно какие-то отголоски изменений, внесенных в компоненту начиная с версии 5.53.1.1004 и далее.
На предыдущих версиях никаких подобных проблем вообще нет.
Надеемся на понимание. И на то, что проблема будет исправлена.
Спасибо.
Добрый день. Поскольку речь идет о проблеме локальных пользователей на местах, то точно сказать не смогу - у всех по-разному просто.
Где-то еще Win 10 Pro, где-то уже Win 11 Pro. Где-то КриптоПро еще 4-й версии (остатки), но в подавляющем большинстве случаев уже 5-я. Типа 5.0.13000 КС1 или 5.0.12000.
Проблема 100% воспроизводилась у нас на Win 10 Pro + КриптоПро 5.0.13000 КС1. Просто буквально на компьютере в метре от моего пробовали с ЭП на флешке работать и получали вышеуказанную проблему.
Добрый день.
Проверили по версии 5.55.0.1018 исправление ошибок, заявленных в описании:
Ошибки из топиков: https://github.com/diadoc/diadocsdk-1c-docs/issues/1159 https://github.com/diadoc/diadocsdk-1c-docs/issues/1165
Действительно исправлены. Проблем в работе теперь нет. Спасибо!
При этом по ошибке из топика https://github.com/diadoc/diadocsdk-1c-docs/issues/1159 есть небольшое расхождение в документации:
Сюда вы добавили указание нового Id = "HasWarnings". НО! В описание самих возможных значений Id не указали этот "HasWarnings" (и его описание!) среди возможных значений:
Что выглядит несколько недоделанным.
НО! Самое главное!
К сожалению ошибка из текущего топика https://github.com/diadoc/diadocsdk-1c-docs/issues/1150, связанного с https://github.com/diadoc/diadocsdk-1c-docs/issues/1107, никак не исправлена!
Поведение на локальных компьютерах пользователей осталось неизменным:
- Пользователь хочет подписать документ.
- Вставляет флешку с ЭП в свой компьютер.
- Нажимает в 1С в документе ЭДО на кнопку "Подписать".
- Мы подключаем компоненту AddIn x64 5.55.0.1018
- Мы получаем список доступных сертификатов.
- Пользователь выбирает из них свой со вставленной флешки.
- Мы выполняем подключение по сертификату.
- В этот момент, т.к. на сертификат установлен пароль - выскакивает окно КриптоПро для ввода пароля. (Т.е. мы с паролем вообще дела не имеем и никак с ним в коде в этой ситуации не работаем!).
- Пользователь вводит пароль.
- Мы подключаем по сертификату.
- Мы выполняем код, формирующий данные для подписания документа:
- (Получаем объект ReplySendTask2 через CreateReplySendTask2("AcceptDocument"), заполняем его и т.д.).
- После заполнения всех необходимых данных мы вызываем метод Send() для заполненного объекта ReplySendTask2.
- И выпадаем в исключение с той же ошибкой, что и ранее: Произошла исключительная ситуация (ReplySendTask2.Send): CRYPTO[0x0000002F] gui authentication requested in silent mode
Т.к., похоже (см. выше), что введенный ранее напрямую в КриптоПро пароль почему-то не учитывается при вызове Send().
Странное ощущение, что починив проблему с SetPin() из топика https://github.com/diadoc/diadocsdk-1c-docs/issues/1107, каким-то образом поломали поведение с паролем вводимым напрямую в окно КриптоПро без использования SetPin().
Возможно, мы не так вас поняли, и ошибка из данного топика еще не прорабатывалась. И по ней пока исправления нет. И оно еще только готовится.
Но выше вы писали попробовать поведение при проблеме на новой версии АПИ. Мы попробовали - проблема не ушла, она осталась.
Очень хотелось бы, чтобы её как-то исправили, т.к. эта ошибка массовая. И она не позволяет нашим пользователям работать с ЭДО локально, используя свои флешки и токены. Т.е. является для нас очень критичной!
Огромная просьба разобраться с этой проблемой!
Надеемся на ваше понимание и содействие.
Спасибо.
@JohnSergeev Добрый день
По ошибке изменения для этого тикета не попали в релизную версию компоненты. Приносим извинения. Сделаем фикс сегодня
Добрый день. Протестировали итоговую версию 5.55.1.1019.
Проблема решена. Предварительно кажется, что вышеописанная проблема исчезла и окно для ввода пароля к ЭП от КриптоПро появляется при подписании корректно и, после ввода пароля, подписание происходит без ошибок.
По идее данный тикет можно закрывать.
Спасибо.