1с сертификат не предназначен для указанного использования
Шифрование - обратимое преобразование некой информации с целью сокрытия от неавторизованных лиц и, в это же время, предоставление, авторизованным пользователям доступа к ней. Главная задача шифрования - это соблюдение конфиденциальности передаваемой информации.
- Симметричное шифрование - использует один и тот же ключ и для зашифрования, и для расшифрования;
- Асимметричное шифрование - использует два разных ключа: один для зашифрования (который также называется открытым), другой для расшифрования (называется закрытым).
Создание временного сертификата
Пример создания временного сертификата для тестирования шифрования в 1С:
makecert.exe -r -pe -n CN="www.example.com" -ss my -sr currentuser
-sky exchange -sp "Microsoft Strong Cryptographic Provider"
2. Создание временного сертификата |
Реализация шифрования
МенеджерКриптографии = Новый МенеджерКриптографии(ИмяКП, "", ТипКП);
ХранилищеСертификатов = МенеджерКриптографии.ПолучитьХранилищеСертификатов(
ТипХранилищаСертификатовКриптографии.ПерсональныеСертификаты,
РасположениеХранилищаСертификатовКриптографии.ДанныеПользователяОС);
Сертификат = ХранилищеСертификатов.НайтиПоОтпечатку(Base64Значение(Отпечаток));
ЗашифрованныеДанные = МенеджерКриптографии.Зашифровать(ИмяВременногоФайла, Сертификат);
УдалитьФайлы(ИмяВременногоФайла);
Возврат Base64Строка(ЗашифрованныеДанные);
МенеджерКриптографии = Новый МенеджерКриптографии(ИмяКП, "", ТипКП);
МенеджерКриптографии.ПарольДоступаКЗакрытомуКлючу = ПарольЗакрытогоКлюча;
РасшифрованныеДанные = МенеджерКриптографии.Расшифровать(Base64Значение(ЗашифрованныеДанные));
ИмяВременногоФайла = ПолучитьИмяВременногоФайла();
РасшифрованныеДанные.Записать(ИмяВременногоФайла);
ЧтениеТекста = Новый ЧтениеТекста(ИмяВременногоФайла, "CESU-8");
СтрокаДанных = ЧтениеТекста.Прочитать();
ЧтениеТекста.Закрыть();
УдалитьФайлы(ИмяВременногоФайла);
Возврат СтрокаДанных;
В данной функции инициализируется менеджер криптографии и указывается пароль к контейнеру закрытого ключа. Далее происходит расшифровка зашифрованных данных. Результатом расшифрования являются двоичные данные, которые записываются в файл с кодировкой CESU-8 и считываются из него.
Может кто подскажет как должен работать механизм проверки подписанного файла в 1С?
Мое видение процесса:
1. Получаем файл от контрагента.
2. В конфигурации должен быть регистр соответствия Сертификатов конкретному Контрагенту.
3. Методом перебора всех сертификатов и проверкой наличия данного сертификата в полученном файле узнаем что это за контрагент.
4. Проверяем действительность сертификата.
Пункт 3 не нравится.
Пункт 4 не знаю как реализовать.
(1) Для начала ответь на вопрос: каким ПО криптографии собираешься пользоваться? Avest, Copicom или нечто другое. Как определишься - выясняешь методы работы выбранной системы.
В идеале, работа с шифрованными данными выглядит так:
1. Получили файл
2. Скормили его системе шифрования, на предмет определения есть подпись или нет
3. Попросили расшифровать, если подпись есть
Вполне вероятно, что п.2 и п.3 выполняются за одно действие.
Не изобретай велосипед, там где он не нужен. До тебя уже всё сделали и придумали как хранить сертификаты (выпуск, отзыв, обмен, локальное хранилище, обмен с выше стоящим УЦ), как проверять их актуальность, как использовать в шифровании/дешифровании данных и проч.
(2) посмотреть бы этот велосипед. :)
про первый вопрос - вообще думал что КриптоПро буду использовать и МенеджерКриптографии.
(3) вот и почитай как работает, где хранит ключи, как получает сертификат, какие функции доступны для программного использования.
Как минимум на сайте производителя.
На сколько я помню, там целая система замкнутая на носитель контейнера, вроде всё на нём и хранится.
Изучил бы для начала предметную область.
А без минимальных знаний в оной вопросы "Как должна работать проверка подписи в 1С" аналогичны "Есть ли жизнь на Марсе?"
ситуация точь в точь как в (5).
Так что предметнаяобласть - она тоже.. разная.. И кой-кому тоже бы не помешало ее подучить. :)
(9) + с первого апреля этого года, проверка хэша в электронной подписи является обязательным условием для юридической значимости документа, если подпись не хранит хэш - документ не имеет силы
Так что для двухстороннего обмена - одно дело. Можно и шифровать, и обменяться открытыми ключами и т.д.
Может кто подскажет как должен работать механизм проверки подписанного файла в 1С?
Мое видение процесса:
1. Получаем файл от контрагента.
2. В конфигурации должен быть регистр соответствия Сертификатов конкретному Контрагенту.
3. Методом перебора всех сертификатов и проверкой наличия данного сертификата в полученном файле узнаем что это за контрагент.
4. Проверяем действительность сертификата.
Пункт 3 не нравится.
Пункт 4 не знаю как реализовать.
(1) Для начала ответь на вопрос: каким ПО криптографии собираешься пользоваться? Avest, Copicom или нечто другое. Как определишься - выясняешь методы работы выбранной системы.
В идеале, работа с шифрованными данными выглядит так:
1. Получили файл
2. Скормили его системе шифрования, на предмет определения есть подпись или нет
3. Попросили расшифровать, если подпись есть
Вполне вероятно, что п.2 и п.3 выполняются за одно действие.
Не изобретай велосипед, там где он не нужен. До тебя уже всё сделали и придумали как хранить сертификаты (выпуск, отзыв, обмен, локальное хранилище, обмен с выше стоящим УЦ), как проверять их актуальность, как использовать в шифровании/дешифровании данных и проч.
(2) посмотреть бы этот велосипед. :)
про первый вопрос - вообще думал что КриптоПро буду использовать и МенеджерКриптографии.
(3) вот и почитай как работает, где хранит ключи, как получает сертификат, какие функции доступны для программного использования.
Как минимум на сайте производителя.
На сколько я помню, там целая система замкнутая на носитель контейнера, вроде всё на нём и хранится.
Изучил бы для начала предметную область.
А без минимальных знаний в оной вопросы "Как должна работать проверка подписи в 1С" аналогичны "Есть ли жизнь на Марсе?"
ситуация точь в точь как в (5).
Так что предметнаяобласть - она тоже.. разная.. И кой-кому тоже бы не помешало ее подучить. :)
(9) + с первого апреля этого года, проверка хэша в электронной подписи является обязательным условием для юридической значимости документа, если подпись не хранит хэш - документ не имеет силы
Так что для двухстороннего обмена - одно дело. Можно и шифровать, и обменяться открытыми ключами и т.д.
Добрый день! Пытаюсь подписать xml-файл созданным сертификатом, но никак не получается. Порядок действий был такой:
1. Выпустил собственный сертификат командой в PowerShell:
2. Скопировал в папку "Доверенные корневые центры сертификации" -> "Сертификаты"
3. В отладчике, в списке, полученном от МенеджерКриптографии нашел свой сертификат
4. Выбрав свой сертфикат, при попытке Подписать() получаю ошибку типа:
Сертификат, связанный с закрытым ключом, указывает на модуль криптографии, отличный от текущего.
Сертификат связан с модулем криптографии "Microsoft Software Key Storage Provider" с типом 0.
Код получения сертификатов и подписи с ИТС
Что делаю не правильно?
(1)
Мда. RTFM.
С чего вы вообще решили, что МенеджерКриптографии.Подписать выдаст вам подпись в формате xmldsig?
Это так не работает. Вот вообще.
Да собственно, все делаете не правильно.
Платформа не умеет подписывать в формате xmldsig.
Но в БСП есть внешняя компонента, которая умеет.
(4) собственно по этому и спрашиваю, что мат. часть по этому вопросу со стороны 1с освещена слабо, а пример с ИТС получается вообще не к этому относится.
Можете ссылку на описание ВК? Или хотя бы ее наименование?
(1)По поводу ошибки при подписи.
При таком создании сертификата провайдер может быть разный, его надо указать явно.
Specifies the name of the KSP or CSP that this cmdlet uses to create the certificate. See Cryptographic Providers for more information. Some acceptable values include:
Microsoft Software Key Storage Provider
Microsoft Smart Card Key Storage Provider
Microsoft Platform Crypto Provider
Microsoft Strong Cryptographic Provider
Microsoft Enhanced Cryptographic Provider v1.0
Microsoft Enhanced RSA and AES Cryptographic Provider
Microsoft Base Cryptographic Provider v1.0
The name of a third party KSP or CSP
У вас создался сертификат с провайдером Microsoft Software Key Storage Provider, а вы создаете менеджер криптографии для провайдера Microsoft Enhanced Cryptographic Provider v1.0, поэтому и ошибка.
(7)Да, так вы не подпишите.
Возьмите демо базу БСП и попробуйте в ней реализовать подпись, используя процедуры и функции общих модулей БСП.
(8) попробовал, проблема с сертификатами.
Вопрос - делали ли уже такую процедуру сами? Если да, то сертификат самовыпущенный? Если да, то как его создавали?
(10)Как-то пробовал, в тот раз не разобрался что передать, чтобы заработало. Больше не пробовал.
Но то что оно работает у других, это точно.
У меня есть сертификат крипто-про.
Самовыпущенные сертификаты не использовал.
Значит, скорее всего, дело в сертификате - чем-то он не соответствует криптопровайдеру, о чем честно говорится в ошибке
ключ сгенерился, но устанавливаться не хочет, скопировал во все места, куда просился, теперь такая беда:
но не могу допереть, как "Установить закрытый ключ" - во всех примерах там КриптоПро и VIPnet, все возможные действия для стандартной оснастки certmgr уже выполнил (добавил в доверенные, в личные, экспортировал и импортировал в локальный компьютер и личную учетную запись).
(25) да, для usr1cv8 тоже.
В свойствах закрытого ключа не нашёл - по картинками должен быть ключик на главной странице свойств и надпись. Но его нет (
Тогда результат из (22) закономерен - система не видит закрытого ключа и поэтому 1С никак не сможет ним работать.
Как минимум надо добиться, чтобы сертификат был связан с закрытым ключом. а потом, не исключено, снова вылезет ошибка из (1).
(22) Картинка "на клиентском компьютере". Так Вы где подпись собираетесь ставить, &НаКлиенте или &НаСервере?
(30) 1) Команда PowerShell добавит самоподписанный с закрытым ключом в личное текущего пользователя ОС - в хранилище админа.
New-SelfSignedCertificate -DnsName "www.mytest.com", "www.whatsthis.com" -Provider "Microsoft Enhanced Cryptographic Provider v1.0" -CertStoreLocation "cert:\CurrentUser\My"
2) Далее его нужно экспортировать с закрытым ключом. Win+R certmgr.msc
3) Потом certmgr.msc нужно запустить под тем пользователем, под которым сервер 1С работает как служба (например USR1CV8), и в личное хранилище этого юзера импортировать файл из шага-2
(30) У меня после того, как сертификат с закрытым ключом появился в личном хранилище сертификатов у пользователя USR1CV8 - начинает работать следующий код:
(22) Если Вы генерировали сертификат по инструкции через certreq.exe -new template.txt outcert.cer - то он должен появиться в остнастке
Win+R
mmc
Ctrl+M
Сертификаты
Учетной записи компьютера
Экспортируем из остнастки этот сертификат с закрытым ключом в файл (название файла задаем, чтобы не перепутать с outcert.cer, т.к. outcert.cer это просто открытый сертификат без закрытого ключа), закрываем консоль. Открываем консоль снова под пользователем USR1CV8 (можно создать ярлык на рабочем столе certmgr.msc и запускать его от имени пользователя USR1CV8) В консоли импортируем файл с закрытым ключом в личное хранилище пользователя USR1CV8.
После всего этого МенеджерКриптографии.Подписать - сможет подписать данным ключом &НаСервере.
Приведенная Вами картинка относится к подписанию из личного хранилища текущего пользователя, НаКлиенте. Если хотите подписывать на клиенте с помощью МенеджераКриптографии - то нужно из файла импортировать сертификат с закрытым ключом в личное хранилище пользователя (админа) - тоже через остнастку certmgr.msc, запущенную от имени админа.
Создание электронной подписи на платформе 1С с помощью СКЗИ КриптоПро CSP можно выполнять как на стороне сервера, так и на стороне клиента. В обоих случаях может появиться довольно неприятная ошибка:
Неправильный параметр набора ключей.
Постановка задачи
Допустим, имеется информационная база, с которой платформа 1С работает в клиент-серверном варианте. Создание электронной подписи будем выполнять на стороне сервера, в этом случае рекомендуется использовать сертификаты и ключи, находящиеся в хранилище локального компьютера, так как они будут доступны любому пользователю Windows. А так же имеется установленный сертификат в хранилище локального компьютера в разделе Личное (см. рисунок 1) с привязкой к закрытому ключу (см. рисунок 2).
Рисунок 1. Сертификат локального хранилища |
Рисунок 2. Сертификат, привязанный к закрытому ключу |
Решение проблемы
Создание ЭП на стороне сервера означает, что данная операция будет выполняться от имени пользователя сервера 1С (USR1CV82 или USR1CV83, в зависимости от версии платформы). Одна из причин появления ошибки неправильного параметра набора ключей - это отсутствие у пользователя доступа к закрытому(секретному) ключу сертификата.
Читайте также: