- How to implement async constructor/factory-call in native c / nodejs addon?
- Itweek
- Uncaught typeerror: undefined is not a function
- Unexpected token ;
- Важная новость для всех пользователей крипто про csp
- Вопросы и ответы
- Как читать ошибки?
- Какие формулировки должны быть в решении об одобрении максимальной суммы сделки?
- Ответы на вопросы по электронным услугам росреестра
- Решение об одобрении крупной сделки несколькими учредителями (образец):
- Решение об одобрении крупной сделки одним учредителем (образец):
- Список методов и свойств обьекта cadesplugin
- Стандартный пароль эцп — где его взять?
- Электронная подпись документов word
How to implement async constructor/factory-call in native c / nodejs addon?
i’m quite new to C and node/v8 Addon development.
I’m trying to wrap a 3rd Party C-Library.
Some initialisation-functions run quite long and I’d like to run those operations async (with help of libuv).
Given i have the following code:
#define BUILDING_NODE_EXTENSION
#include <node.h>
#include "myobject.h"
//header files of 3rd party lib to be wrapped
#include "3rdparty.h"
using namespace v8;
MyObject::MyObject(void* base) : baseobject_(base) {};
MyObject::~MyObject() {};
void MyObject::Init(Handle<Object> target) {
// Prepare constructor template
Local<FunctionTemplate> tpl = FunctionTemplate::New(New);
tpl->SetClassName(String::NewSymbol("MyObject"));
tpl->InstanceTemplate()->SetInternalFieldCount(1);
Persistent<Function> constructor = Persistent<Function>::New(tpl->GetFunction());
target->Set(String::NewSymbol("MyObject"), constructor);
}
Handle<Value> MyObject::New(const Arguments& args) {
HandleScope scope;
if (args.IsConstructCall())
{
void* cStruct = NULL;
//
//VERY LONG TAKING OPERATION
//Want to run this async with help of libuv
createStructIn3rdPartyLib(&cStruct);
//create actual Object and pass in cStruct which becomes private field.
MyObject* obj = new MyObject(cStruct);
obj->Wrap(args.This());
return args.This();
}
return scope.Close(Undefined());
}
I want to run createStructIn3rdPartyLib(&cStruct);
with the help of the libuv-library.
The following is what i came up with. Unfortunately it gives me a Segmentation Fault and I’m not quite sure if it’s even the right approach.
I’v already looked into source of other native node-addons, but did not find any solution for my Problem. 🙁
Any hints welcome.
#define BUILDING_NODE_EXTENSION
#include <node.h>
#include "myobject.h"
//header files of 3rd party lib to be wrapped
#include "3rdparty.h"
using namespace v8;
// libuv allows us to pass around a pointer to an arbitrary
// object when running asynchronous functions. We create a
// data structure to hold the data we need during and after
// the async work.
typedef struct AsyncData {
Persistent<Function> callback; // callback function
void *3rdpartydata
Arguments *args;
} AsyncData;
MyObject::MyObject() {};
MyObject::~MyObject() {};
void MyObject::Init(Handle<Object> target) {
// Prepare constructor template
Local<FunctionTemplate> tpl = FunctionTemplate::New(New);
tpl->SetClassName(String::NewSymbol("MyObject"));
tpl->InstanceTemplate()->SetInternalFieldCount(1);
Persistent<Function> constructor = Persistent<Function>::New(tpl->GetFunction());
target->Set(String::NewSymbol("MyObject"), constructor);
target->Set(String::NewSymbol("createObject"),
FunctionTemplate::New(New)->GetFunction(CreateObjectAsync));
}
Handle<Value> MyObject::New(const Arguments& args) {
HandleScope scope;
if (args.IsConstructCall())
{
void* cStruct = NULL;
//
//VERY LONG TAKING OPERATION
//Want to run this async with help of libuv
createStructIn3rdPartyLib(&cStruct);
//create actual Object and pass in cStruct which becomes private field.
MyObject* obj = new MyObject(&cStruct);
obj->Wrap(args.This());
return args.This();
}
return scope.Close(Undefined());
}
Handle<Value> MyObject::CreateObjectAsync(const Arguments& args)
{
HandleScope scope;
// create an async work token
uv_work_t *req = new uv_work_t;
// assign our data structure that will be passed around
AsyncData *asyncData = new AsyncData();
req->data = asyncData;
// expect a function as the 1st argument
// we create a Persistent reference to it so
// it won't be garbage-collected
asyncData->callback = Persistent<Function>::New(
Local<Function>::Cast(args[0]));
*(asyncData->args) = args;
// pass the work token to libuv to be run when a
// worker-thread is available to
uv_queue_work(
uv_default_loop(),
req, // work token
AsyncWork, // work function
(uv_after_work_cb)AsyncAfter // function to run when complete
);
return scope.Close(Undefined());
}
// Function to execute inside the worker-thread.
// It is not safe to access V8, or V8 data structures
// here, so everything we need for input and output
// should go on our req->data object.
void MyObject::AsyncWork(uv_work_t *req) {
// fetch our data structure
AsyncData *asyncData = (AsyncData *)req->data;
// run 3rd Party Function.
createStructIn3rdPartyLib(&asyncData->3rdpartydata);
}
// Function to execute when the async work is complete
// this function will be run inside the main event loop
// so it is safe to use V8 again
void MyObject::AsyncAfter(uv_work_t *req) {
HandleScope scope;
// fetch our data structure
AsyncData *asyncData = (AsyncData *)req->data;
// create an arguments array for the callback
MyObject *cpBase = new MyObject(asyncData->3rdpartydata);
cpBase->Wrap((*asyncData->args).This());
Handle<Value> argv[] = {Null(),(*asyncData->args).This()};
// surround in a try/catch for safety
TryCatch try_catch;
// execute the callback function
asyncData->callback->Call(Context::GetCurrent()->Global(), 2, argv);
if (try_catch.HasCaught())
node::FatalException(try_catch);
// dispose the Persistent handle so the callback
// function can be garbage-collected
asyncData->callback.Dispose();
// clean up any memory we allocated
delete asyncData;
delete req;
}
Thank you!!!
Edit:
I after reading more examples like the node-ogg bindings i’m thinking more and more that i’m on the wrong track with my approach. Maybe i should stay on a much lower level at the C/C -Side and implement Object-Functionality on the javascript-side.
Itweek
Некоторое время назад в группе «ECM Forum Rus» на фейсбуке произошла
дискуссия
по вопросам применения электронной подписи в информационных системах органов власти (обсуждение было не по теме топика, можно посмотреть в нижних комментариях). Суть спора — из-за OID’ов (object identifier — идентификатор объекта) информационных систем, которые необходимо прописывать в квалифицированных сертификатах электронной подписи (ЭП) должностных лиц, эти самые ЭП приходится менять даже чаще чем раз в год (что диктуется требованиями безопасности), а это, в свою очередь, ведет к дополнительным сложностям и издержкам, так как большинство органов работают с коммерческими УЦ, не имея собственных. Проблема усугубляется отсутствием общего понимания, что именно эти OID дают и насколько они необходимы и/или обязательны.
В ходе спора мой оппонент предупредил меня, что из-за незнания некоторых основ предметной области я могу в будущем получить определенные проблемы с законом. Такое предупреждение от коллеги я не мог оставить без внимания, поэтому решил еще раз внимательно исследовать эту тему и убедиться, что все понимаю и делаю правильно. Ниже привожу некоторые результаты этого экскурса в предметную область. Возможно кому-то будет интересно.
Если начинать с базовых понятий, электронное подписание основывается на асимметричных алгоритмах шифрования. Основная особенность этих алгоритмов в том, что для шифрования и расшифровки сообщения используются два разных ключа. Широкой общественности более знакомы симметричные алгоритмы, когда одним ключом (или паролем) мы и шифруем и расшифровываем сообщение, например архивируем файл с паролем или защищаем документ MS Word.
На асимметричных алгоритмах шифрования основаны многие вещи, хотя сам по себе тот факт, что для шифрования и расшифровки используются разные ключи, ещё не позволил бы найти сколько-нибудь полезного применения этим алгоритмам. Для этого они должны обладать ещё некоторыми дополнительными свойствами. Во-первых, ключи не должны быть вычисляемыми, то есть зная один ключ вы не можете вычислить второй. Также очень важно, чтобы разным ключам шифрования соответствовали разные ключи расшифровки и наоборот — одному ключу расшифровки соответствовал только один ключ шифрования.
При чем тут собственно подпись? Ведь нам надо подписать документ, а не зашифровать его. Для начала надо разобраться, что такое собственно подпись и для чего она нужна. Когда вы ставите свою собственноручную подпись на бумажный документ, вы тем самым заверяете, что именно вы (а не кто-то другой) видели (и согласны) именно этот документ (а не какой-то другой). Важнейшее свойство подписи — неотрекаемость (non-repudiation). Это означает, что подписав документ, вы не можете позже отказаться от этого факта. В случае бумажной подписи вас уличит графологическая экспертиза, в случае электронной — математические методы, основанные на асимметричных алгоритмах шифрования.
Как все это работает, в двух словах. Берем асимметричный алгоритм шифрования, генерируем пару ключей (для шифрования и расшифровки). Ключ шифрования даем человеку, который будет подписывать документы. Он его должен всегда держать при себе и никому не давать. Поэтому его называют «закрытый» ключ. Другой ключ (расшифровки) даем всем желающим, поэтому он «открытый». Подписывая документ, человек должен зашифровать его своим закрытым ключом. На самом деле шифруется не сам документ, так как он может быть достаточно большим, а нам вообще-то и не нужно его шифровать. Поэтому по документу получают хэш — это некая числовая последовательность с большой долей вероятности разная для разных документов, как бы «отпечаток» документа. Его и шифруют закрытым ключом подписанта. Этот зашифрованный хэш и есть электронная подпись документа. Теперь имея документ, подпись и открытый ключ, любой может легко проверить, что именно этот документ был подписан именно этим закрытым ключом. Для этого снова получаем хэш документа, расшифровываем открытым ключом подпись и сравниваем. Должны получить две идентичные числовые последовательности.
Все это прекрасно, но пока мы получили неотрекаемость подписи для закрытого ключа, то есть доказали, что документ подписан конкретным ключом. Нам же необходимо доказать, что он был подписан конкретным человеком. Для этого существуют удостоверяющие центры и цифровые сертификаты. Самое важное, что делает удостоверяющий центр — он удостоверяет, что закрытый ключ принадлежит конкретному лицу. Чтобы это гарантировать, именно удостоверяющий центр генерирует пары ключей и выдает их лично в руки владельцам (есть варианты по доверенности, удаленно, но это уже детали). Вместе с ключами генерируется цифровой сертификат — это электронный документ (бывает и бумажное его представление), в котором содержится информация о владельце ключа, самом ключе, удостоверяющем центре и некоторая другая информация. Владелец, как правило, получает все это добро на защищенном носителе (смарт-карте, ру-токене и так далее), на котором содержится закрытый ключ и сертификат с внедренным открытым ключом. Сам носитель необходимо всегда держать при себе, а скопированный с него сертификат с открытым ключом можно давать всем желающим, чтобы они могли проверить вашу электронную подпись.
Итак, подписание производится закрытым ключом, а проверка подписи открытым. Поэтому фраза «документ подписывается набором OID» (прозвучавшая в упомянутом споре) лишена всякого смысла. В процедуре подписания и проверки участвуют только два ключа, в 63-ФЗ они и названы соответственно — ключ подписи и ключ проверки подписи.
А что такое эти пресловутые OID? Формат цифрового сертификата X.509 позволяет сохранять в нем расширения (extensions). Это некие необязательные атрибуты, при помощи которых можно хранить дополнительную информацию. Каждый такой атрибут является объектом, который задается идентификатором из иерархического справочника. Отсюда OID — Object Identifier. Углубляться в природу самих OID здесь смысла нет. По сути это некоторая дополнительная информация, которая может присутствовать в сертификате.
Данные дополнительные атрибуты могут использоваться для разных целей. Они могут либо предоставлять дополнительную информацию о владельце, ключах, УЦ, либо нести какую-то дополнительную информацию для приложений и сервисов, которые этот сертификат используют. Самое распространенное применение — это управление доступами на основе ролей. Например, в сертификате можно прописать, что владелец ключа является руководителем организации, и это даст ему возможность сразу во всех ИС получить доступ к нужным функциям и сведениям, без необходимости связываться с администраторами каждой ИС и менять настройки доступа. Все это конечно при условии, что все эти ИС используют сертификат пользователя для его авторизации и анализируют один и тот-же атрибут одинаковым образом (для того-то атрибуты и выбираются из справочника, а не задаются произвольно).
Из-за различного применения мы получаем два совершенно разных по природе сертификата. Один — удостоверяет, что я это я, а это всегда так. По хорошему его можно было бы выдавать один или несколько раз в жизни, как паспорт. Однако, из-за несовершенства существующих криптографических алгоритмов, в целях безопасности, данные сертификаты сейчас необходимо переоформлять каждый год. Второй вид сертификата управляет дополнительной информацией и может меняться гораздо чаще, чем даже раз в год. Его можно сравнить с визитной карточкой. Изменилась должность, электронная почта, телефон — надо делать новые визитки.
В мире эти два вида сертификатов называются соответственно Public Key Certificate (PKC) и Attribute Certificate (или Authorization Certificate — AC). Сертификат второго рода может выпускаться гораздо чаще первого, другой организацией и должен быть доступнее и проще в получении, чем персональный сертификат «открытого ключа». Во всяком случае, так рекомендует RFC 3281, посвященный этому виду сертификатов. Сертификат второго рода должен содержать лишь ссылку на сертификат открытого ключа, чтобы система, использующая его для авторизации пользователя, могла сначала идентифицировать персону при помощи PKC.
Теперь перенесемся ближе к нашим реалиям. На законодательном уровне вопросы, связанные с применением электронной подписи в Российской Федерации, регулируются двумя основными документами — законом РФ от 06.04.2020 №63-ФЗ «Об электронной подписи» и приказом ФСБ РФ от 27.12.2020 №795 «Об утверждении требований к форме квалифицированного сертификата ключа проверки электронной подписи». Состав квалифицированного сертификата описан в 795-м приказе (ч. II «Требования к совокупности полей квалифицированного сертификата») и в нем нет требований к атрибутам, управляющим авторизацией в каких-либо информационных системах. В качестве дополнительных обязательных атрибутов указаны лишь сведения, позволяющие идентифицировать физическое или юридическое лицо в РФ (ИНН, СНИЛС и т. д.). Хотя ни закон ни приказ ФСБ не запрещают включать в квалифицированный сертификат другие сведения.
Как видим, никакие законодательные нормы не диктуют обязательного наличия в квалифицированном сертификате атрибутов, связанных с авторизацией в каких-либо информационных системах. Откуда тогда эти требования берутся? А исходят они от разработчиков (или «владельцев») конкретных систем. Возьмём например «Методические рекомендации по использованию электронной подписи при межведомственном электронном взаимодействии (версия 4.3)», размещенные на технологическом портале СМЭВ. Действительно, в пункте 6 данного документа читаем: «При подготовке сведений для формирования сертификата ЭП-СП необходимо определить необходимость запроса сведений из Росреестра (выписки из ЕГРП). При необходимости такого запроса в поле “Улучшенный ключ” (OID=2.5.29.37) в сертификате ЭП-СП должен быть указан OID по требованиям Росреестра.». То есть информационная система Росреестра использует этот атрибут для определения сведений, которые можно выдавать владельцу сертификата. Однако этот же документ содержит важное примечание, а именно — данное требование действует до полного запуска ЕСИА (единый сервис авторизации в гос. системах) и подключения к ней системы Росреестра. Это важное замечание, запомним его.
Не буду разбираться с другими ИС, применяемыми в гос. органах. Подозреваю, что там ситуация похожая. Портал госзакупок, электронные торговые площадки, различные бухгалтерские и финансовые приложения также могут требовать наличия тех или иных дополнительных OID в сертификате пользователя. При этом утверждение, что прописывая OID информационной системы в сертификате, я каким-либо образом делегирую ответственность удостоверяющему центру, мягко говоря, неверно. УЦ вносит эти данные в сертификат согласно моей заявки. Если у меня изменилась должность, а я забыл подать заявку на отзыв старого и выпуск нового сертификата, УЦ никак не может отвечать за мою забывчивость. К тому-же закон 63-ФЗ прямо закрепляет ответственность за неправильное использование сертификата за его владельцем. В пункте 6 статьи 17 читаем:
Владелец квалифицированного сертификата обязан:
1) не использовать ключ электронной подписи и немедленно обратиться в аккредитованный удостоверяющий центр, выдавший квалифицированный сертификат, для прекращения действия этого сертификата при наличии оснований полагать, что конфиденциальность ключа электронной подписи нарушена;
2) использовать квалифицированную электронную подпись в соответствии с ограничениями, содержащимися в квалифицированном сертификате (если такие ограничения установлены).
Необходимость хранить в сертификате сведения о ролях и доступах пользователя в конкретных информационных системах приводит к проблеме, из-за которой разгорелся спор в фейсбуке, а именно — сертификат приходится перевыпускать гораздо чаще, чем это диктуют требования безопасности к персональной электронной подписи. Поменялась должность — перевыпускаем сертификат. Появилась новая ИС — перевыпускаем сертификат. Появилась необходимость запроса сведений из ИС новой организации (Росреестр) — перевыпускаем сертификат.
Налицо стопроцентное попадание в концепцию, именуемую в мире Attribute Certificate (или Authorization Certificate), о которой говорилось выше и при которой рекомендуется выпускать эти сертификаты другим удостоверяющим центром (Attribute Autority, в отличие от Certificate Authority — обычного УЦ, выпускающего квалифицированные сертификаты ЭП) и по упрощенной схеме. Этот сертификат сам по себе не должен содержать ключа электронной подписи и информации о владельце. Вместо этого он содержит ссылку на сертификат открытого ключа владельца, из которого можно получить остальную необходимую информацию о персоне.
Необходимо заметить, что и эта схема имеет весьма ограниченное применение и не решает всех проблем. Что если очередная информационная система решит использовать то-же поле сертификата “Улучшенный ключ” (OID=2.5.29.37), которое уже занято значением Росреестра, для своих нужд? Вписать два разных значения в одно поле не получится. Следовательно придется выпускать ещё один AC! Другая проблема связана с коротким временем жизни PKC (один год). Если имеем несколько AC (в которых содержится ссылка на персональный сертификат), их все придется перевыпустить по истечении срока PKC. Для эффективного применения AC необходим некий единый центр авторизации пользователей во всех информационных системах, а все приложения должны согласованно и единообразно использовать атрибуты сертификатов.
Такой единый центр авторизации для гос. органов уже есть — это ЕСИА. Вспомним про примечание, касающееся OID’ов Росреестра. В будущем они будут заменены информацией из ЕСИА. Так же должны поступать и прочие информационные системы, в которых работают гос. служащие. Вместо использования AC для авторизации, необходимо интегрироваться с ЕСИА и получать необходимую информацию оттуда. ЕСИА должна иметь возможность привязки квалифицированного сертификата ЭП к учетной записи, таким образом информационные системы смогут проводить аутентификацию пользователя по персональному ключу, а его авторизацию (предоставление доступа к приложению) через ЕСИА. Такая система представляется универсальней и надежней, чем применение полей сертификатов, а в перспективе позволит автоматизировать управление доступами. Если будет создана единая система кадрового учета гос. служащих, ЕСИА сможет брать информацию о полномочиях того или иного лица непосредственно оттуда. Перевелся человек на другую должность — автоматически потерял доступ к одним системам и получил к другим. При этом он продолжает пользоваться своим ключом ЭП для подписания документов, ничего перевыпускать не нужно.
Вывод — OID’ы информационных систем в сертификате, не являясь абсолютным злом сами по себе, требуют взвешенного применения. У данного подхода есть альтернативы, которые стоит рассмотреть, например единые сервисы авторизации.
Uncaught typeerror: undefined is not a function
Связанные ошибки:
number is not a function, object is not a function, string is not a function, Unhandled Error: ‘foo’ is not a function, Function Expected
Возникает при попытке вызова значения как функции, когда значение функцией не является. Например:
var foo = undefined;
foo();
Эта ошибка обычно возникает, если вы пытаетесь вызвать функцию для объекта, но опечатались в названии.
var x = document.getElementByID('foo');
Несуществующие свойства объекта по-умолчанию имеют значение
undefined
, что приводит к этой ошибке.
Другие вариации, такие как “number is not a function” возникают при попытке вызвать число, как будто оно является функцией.
Как исправить ошибку: убедитесь в корректности имени функции. Для этой ошибки, номер строки обычно указывает в правильное место.
Unexpected token ;
Связанные ошибки:
Expected ), missing ) after argument list
Интерпретатор JavaScript что-то ожидал, но не обнаружил там этого. Обычно вызвано пропущенными фигурными, круглыми или квадратными скобками.
Токен в данной ошибке может быть разным — может быть написано “Unexpected token ]”, “Expected {” или что-то еще.
Как исправить ошибку: иногда номер строки не указывает на правильное местоположение, что затрудняет исправление ошибки.
Ошибка с [ ] { } ( ) обычно вызвано несовпадающей парой. Проверьте, все ли ваши скобки имеют закрывающую пару. В этом случае, номер строки обычно указывает на что-то другое, а не на проблемный символ.
Unexpected / связано с регулярными выражениями. Номер строки для данного случая обычно правильный.
Unexpected; обычно вызвано символом; внутри литерала объекта или массива, или списка аргументов вызова функции. Номер строки обычно также будет верным для данного случая.
Важная новость для всех пользователей крипто про csp
Согласно письму ФСБ России №149/7/6-363 от 07.09.2020, которое указано в «Уведомлении об организации перехода на использование схемы электронной подписи по ГОСТ Р 34.10-2020» Минкомсвязи России, процесс формирования и проверки ЭП по ГОСТ Р 34.10-2001 был продлен до 31.12.2020.
По причине технических ограничений в средствах криптографической защиты информации «КриптоПро CSP» (далее – СКЗИ), ЭП, соответствующие ГОСТ Р 34.10-2001, будут блокироваться после 31.12.2020.
Поэтому до 01.01.2020 необходимо внести изменения в настройки СКЗИ для обеспечения их корректной работы с помощью специальной утилиты.
Для удобства пользователей предыдущих версий КриптоПро CSP (до новейшей 4.0 R4), которые планируют продолжать работать в 2020 году с ключами ГОСТ Р 34.10-2001, был сделан инструмент для Windows, позволяющий за один вызов снять технические запреты.
Вопросы и ответы
2. Вопрос: Что делать, если возникает ошибка: «Неизвестный криптографический алгоритм»?
Ответ: В случае Windows x64 Необходимо удалить две ветки реестра: [HKEY_LOCAL_MACHINESOFTWAREMicrosoftCryptographyOID EncodingType 0CryptDllFindOIDInfo1.2.643.2.1.3.2.1!1]
[HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoft CryptographyOIDEncodingType 0CryptDllFindOIDInfo1.2.643.2.1.3.2.1!1]
В случае Windows x32 необходимо удалить одну ветку реестра:
[HKEY_LOCAL_MACHINESOFTWAREMicrosoftCryptographyOID EncodingType 0CryptDllFindOIDInfo1.2.643.2.1.3.2.1!1]
3. Вопрос: При формировании запроса в онлайн-портале ФЗС в ОС Windows 10 возникает ошибка: «Объект не поддерживает свойство или метод “CreateObject”». Что делать?
Ответ: По умолчанию в операционной системе Windows 10 используется браузер Microsoft Edge, на нем не работает портал ФЗС. На портал ФЗС нужно заходить только с помощью браузера Internet Explorer версии 9.0. и выше.
4. Вопрос: Не можем попасть в запрос, созданный в ФЗС через первичную подачу документов, сохранился только номер запроса. Что делать?
Ответ: К сожалению, попасть в данный запрос уже нельзя. Для дальнейшей работы с созданным запросом необходимо сохранить не только номер запроса, но и ссылку на сам запрос (см. скриншот). Для подачи документов необходимо заново создать запрос на сертификат.
5. Вопрос: Необходимо ли организации-заявителю получать КриптоПро в Удостоверяющем центре, если у неё уже есть свое КриптоПро?
Ответ: Для работы в информационных системах Федерального казначейства необходимо иметь версию КриптоПро 4.0 или выше. Если у организации-заявителя имеется дистрибутив и достаточное количество лицензий, то нет необходимости в получении новых.
6. Вопрос: Как получить СКЗИ КриптоПро 4.0?
Ответ: Для получения СКЗИ необходимо предоставить в Удостоверяющий центр:
б) оптический носитель однократной записи (CD-R, DVD-R).
7. Как установить новые корневые сертификаты?
8. Вопрос: При формировании ЭП с помощью онлайн портала невозможно выбрать полномочия по 44-ФЗ, как быть?
9. Вопрос: Как найти контейнер (закрытый ключ) от сертификата?
1) В реестр компьютера, на котором создавался запрос на сертификат (в случае, если программа не предложила выбрать носитель для сохранения контейнера);
2) На носителе, который был вставлен в компьютер в момент формирования запроса, и который Вы выбрали (USB-Flash, Rutoken и пр.) Чтобы посмотреть контейнеры, которые доступны на компьютере, откройте “КриптоПРО CSP”, вкладку “Сервис”, нажмите “Просмотреть сертификаты в контейнере” и “Обзор”. Откроется окно со списком доступных контейнеров, их номера и место хранения. Номер контейнера, как правило, соответствует дате и времени его формирования. Например, контейнер с номером 420212233 формировался 20 апреля (20.04) в 11часов 22 минуты 33 секунды.
Как читать ошибки?
Перед самим списком, давайте быстро взглянем на структуру сообщения об ошибке. Понимание структуры помогает понимать ошибки, и вы получите меньше проблем, если наткнетесь на ошибки, не представленные в этом списке.
Типичная ошибка из Chrome выглядит так:
Uncaught TypeError: undefined is not a function
Структура ошибки следующая:
- Uncaught TypeError: эта часть сообщения обычно не особо полезна.
Uncaught
значит, что ошибка не была перехвачена вcatch
, аTypeError
— это название ошибки. - undefined is not a function: это та самая часть про ошибку. В случае с сообщениями об ошибках, читать их нужно прямо буквально. Например, в этом случае, она значит то, что код попытался использовать значение
undefined
как функцию.
Другие webkit-браузеры, такие как Safari, выдают ошибки примерно в таком же формате, как и Chrome. Ошибки из Firefox похожи, но не всегда включают в себя первую часть, и последние версии Internet Explorer также выдают более простые ошибки, но в этом случае проще — не всегда значит лучше.
Теперь к самим ошибкам.
Какие формулировки должны быть в решении об одобрении максимальной суммы сделки?
У нас должно быть два вопроса:
- Выбор способа подтверждения принятого решения и состава участников общества согласно п. 3 ст. 67.1 ГК РФ;
- Одобрение и совершение по результатам электронных аукционов сделок.
Теперь нужно определиться какие формулировки должны быть у принятых решений по вышеназванным вопросам.
По первому вопросу решение должно звучать так:В соответствии с пунктом 3 статьи 67.1 Гражданского кодекса РФ принятие общим собранием участников Общества решения и состав участников Общества, присутствовавших при его принятии, подтверждается путем подписания протокола всеми участниками общества.
По второму вопросу решение должно звучать так:Одобрить и совершать по результатам электронных аукционов сделки от имени Общества с ограниченной ответственностью “Ромашка”. Максимальная сумма одной такой сделки не должна превышать 500 000 000 ( пятьсот миллионов ) рублей.
Ответы на вопросы по электронным услугам росреестра
Электронные услуги Росреестра пользуются все большей популярностью. Сегодня почти все ведомства предоставляют государственные услуги в электронном виде. Электронные услуги Росреестра доступны всем заявителям на официальном сайте Росреестра rosreestr.ru и портале государственных услуг Российской Федерации.
Одна из главных и приоритетных задач Управления – это максимально упростить предоставление услуг для граждан, юридических лиц, органов государственной власти и органов местного самоуправления.
В связи с этим, специалисты подготовили ответы на самые распространенные вопросы заявителей.
Что нужно, для того, чтобы иметь возможность пользоваться услугами Росреестра в электронном виде?
Ответ: Чтобы воспользоваться сервисом, необходимо авторизоваться, то есть иметь логин и пароль на сайте www.gosuslugi.ru (используется Единая система идентификации и аутентификации для получения доступа к государственным услугам в электронном виде).
В настоящее время в личном кабинете можно подать в электронном виде заявление на получение всех наиболее востребованных услуг Росреестра: это регистрация прав, кадастровый учет, единая процедура (одновременное проведение этих процедур), получение сведений из ЕГРН. Для осуществления юридически значимых действий потребуется электронная подпись.
Какое дополнительное программное обеспечение необходимо установить на компьютере для получения государственных услуг, оказываемых Росреестром в электронном виде на официальном сайте Росреестра с применением усиленной квалифицированной электронной подписи?
Ответ: Для получения государственных услуг, оказываемых Росреестром в электронном виде, на официальном сайте Росреестра (rosreestr.ru) с возможностью подписания форм запросов усиленной квалифицированной электронной подписью (далее – ЭП, на компьютере необходимо:
— установить криптопровайдер, при помощи которого в удостоверяющем центре был изготовлен квалифицированный сертификат ключа проверки электронной подписи (например «Крипто-Про CSP»);
— установить квалифицированный сертификат ключа проверки ЭП удостоверяющего центра, выдавшего ЭП пользователю;
— установить квалифицированный сертификат ключа проверки ЭП пользователя;
— установить свободно распространяемый компонент Microsoft CAPICOM;
— зарегистрировать библиотеку CAPICOM.dll;
— в свойствах интернета добавить в надежные узлы адрес: https://*.rosreestr.ru.
Следует иметь ввиду, что программный продукт Microsoft CAPICOM имеет ряд требований к системе, с которыми можно ознакомиться на сайте производителя.
Если после выполнения вышеуказанных действий будет появляться ошибка, связанная с CAPICOM, рекомендуем обратиться в службу технической поддержки производителя программного продукта.
Квалифицированный сертификат ключа проверки электронной подписи с объектным идентификатором 1.2.643.5.1.24.2.30 выпускается на юридическое или физическое лицо?
Объектному идентификатору 1.2.643.5.1.24.2.30 (по распоряжению Росреестра от 20.05.2020 № Р/0083) соответствует категория заявителя «Юридическое лицо», исходя из чего изготавливается квалифицированный сертификат ключа проверки электронной подписи юридического лица. В качестве владельца такого сертификата, наряду с указанием наименования юридического лица, указывается физическое лицо, действующее от имени юридического лица на основании учредительных документов юридического лица или доверенности.
Запросы Администрации муниципального района обрабатываются с ошибкой. Что не так?
Ответ: Квалифицированный сертификат ключа проверки электронной подписи, содержащийся в электронной подписи (далее – сертификат), которой подписаны запросы, содержит объектный идентификатор (далее – ОИД) 1.2.643.5.1.24.2.1.3. Данному ОИДу соответствует субъект/получатель – Правообладатель – физическое лицо.
Судя по тому, что сертификат выдан на Администрацию муниципального района (представитель Иванов Иван Иванович), прописанный в сертификате ОИД не соответствует полномочиям владельца сертификата. По этой причине и возникли проблемы при создании запросов.
В случае, если Администрации муниципального района необходимо формировать запросы о предоставлении сведений из ЕГРН в качестве лица, имеющего право на безвозмездное получение сведений, то ОИД необходимо выбрать соответствующий правовому статусу Администрации муниципального района (устав, положение).
Исходя из вышесказанного предлагаем Администрации муниципального района обратиться в удостоверяющий центр, выдавший усиленную квалифицированную электронную подпись, для перевыпуска сертификата с соответствующим ОИД.
Каким образом подать заявление на регистрацию ограничения права и обременения через личный кабинет Росреестра, если у здания имеются 2 собственника. Подавать 2 заявления от двух собственников с разных личных кабинетов или одно заявление с одного личного кабинета?
Ответ: Посредством Личного кабинета официального сайта Росреестра можно формировать несколько заявлений. В вашем случае необходимо сформировать два заявления на регистрацию ограничения права и обременения под учетной записью одного из собственников.
Главный специалист-эксперт отдела эксплуатации информационных систем,
технических средств и каналов связи С.Б. Ханхаева
Решение об одобрении крупной сделки несколькими учредителями (образец):
С 01.09.2020 в Гражданский Кодекс РФ были внесены поправки касательно способа подтверждения решений, принятых на общих собраниях акционерных общества.
В частности, нас интересует пункт 3 статьи 67.1 ГК РФ «Особенности управления и контроля в хозяйственных товариществах и обществах». Цитируем данный пункт 3:
«Принятие общим собранием участников хозяйственного общества решения и состав участников общества, присутствовавших при его принятии, подтверждаются в отношении: ….…. общества с ограниченной ответственностью путем нотариального удостоверения, если иной способ (подписание протокола всеми участниками или частью участников; с использованием технических средств, позволяющих достоверно установить факт принятия решения; иным способом, не противоречащим закону) не предусмотрен уставом такого общества либо решением общего собрания участников общества, принятым участниками общества единогласно.»
пункт 3 статьи 67.1 ГК РФ
Конечно, никому не хочется заверять решение о максимальной сумме сделки нотариально, поэтому при проведении общего собрания участников по вопросу одобрения максимальной суммы сделок, нужно не забыть и внести в повестку дня ещё один важный вопрос: «Выбор способа подтверждения принятого решения и состава участников общества согласно п. 3 ст. 67.1 ГК РФ».
Наличие в повестке собрания данного вопроса лишает нас необходимости нотариального заверения Протокола Общего собрания.
Решение об одобрении крупной сделки одним учредителем (образец):
Если в компании один участник (учредитель) тогда Решение о крупной сделке оформляется Решением Единственного участника Общества. Такой вариант оформления проще чем решение нескольких учредителей, поскольку вместо собрания участников общества, решение о крупной сделки принимает один единственный учредитель.
В Решении единственного учредителя об одобрении крупной сделки следует указать паспортные данные единственного участника общества, и озвучить принятое решение придерживаясь формулировки:«Одобрить и совершать по результатам открытых аукционов в электронной форме сделки от имени Общества с ограниченной ответственностью «Ромашка»».
Также рекомендуется вторым решением прописать, что учредитель подтверждает полномочия своего Генерального директора на участие в электронных торгах. Даже если сам Учредитель является Директором рекомендуется данный пункт прописывать в Решении о максимальной сумме сделки.
В конце Решения единственного участника должна быть его подпись, печать компании и дата принятия решения.
Список методов и свойств обьекта cadesplugin
Название метода или свойства | Описание |
---|---|
CreateObject(objname) | Cоздает и возвращает обьект типа objname. Доступен в браузерах с поддержкой NPAPI и Internet Explorer. |
CreateObjectAsync(objname) | Cоздает обьект типа objname и возвращает Promise на созданный обьект. Доступен в браузерах Chrome(Chromium), Opera и Яндекс.Браузер. |
async_spawn(function*(){}) | Функция принимающая на вход функцию генератор и позволяющая “синхронизировать” асинхронную работу с Promise при использовании совместно с ключевым словом yield. |
set_log_level(log_level) | Устанавливает уровень ведения логов в log_level. Аргумент может принимать значения cadesplugin.LOG_LEVEL_DEBUG (отладочные, информационные сообщения и ошибки), cadesplugin.LOG_LEVEL_INFO(информационные сообщения и ошибки), cadesplugin.LOG_LEVEL_ERROR(только ошибки). |
getLastError(exception) | Возвращает строку с описанием ошибки из исключения, порождённого плагином. Для Firefox данный метод является единственным способом получения кода ошибки и её текстового описания от плагина. |
JSModuleVersion | Возвращает версию JavaScript-модуля. |
ReleasePluginObjects() | Удаляет объекты, созданные плагином. В случае успеха возвращает true. |
Для удобства в объект cadesplugin добавлены свойства, содержащие значения констант, используемых в различных вызовах плагина.
Название свойства | Описание |
---|---|
CADESCOM_STRING_TO_UCS2LE = 0x00 | Данные будут перекодированы в UCS-2 little endian. |
CADESCOM_BASE64_TO_BINARY = 0x01 | Данные будут перекодированы из Base64 в бинарный массив. |
CAPICOM_LOCAL_MACHINE_STORE = 1 | Локальное хранилище компьютера. |
CAPICOM_CURRENT_USER_STORE = 2 | Хранилище текущего пользователя. |
CADESCOM_LOCAL_MACHINE_STORE = 1 | Локальное хранилище компьютера. |
CADESCOM_CURRENT_USER_STORE = 2 | Хранилище текущего пользователя. |
CADESCOM_CONTAINER_STORE = 100 | Хранилище сертификатов в контейнерах закрытых ключей. В данный Store попадут все сертификаты из контейнеров закрытых ключей которые доступны в системе в момент открытия. |
CAPICOM_MY_STORE = “My” | Хранилище персональных сертификатов пользователя. |
CAPICOM_STORE_OPEN_MAXIMUM_ALLOWED = 2 | Открывает хранилище на чтение/запись, если пользователь имеет права на чтение/запись. Если прав на запись нет, то хранилище открывается за чтение. |
CADESCOM_XML_SIGNATURE_TYPE_ENVELOPED = 0 | Вложенная подпись. |
CADESCOM_XML_SIGNATURE_TYPE_ENVELOPING = 1 | Оборачивающая подпись. |
CADESCOM_XML_SIGNATURE_TYPE_TEMPLATE = 2 | Подпись по шаблону. |
XmlDsigGost3410UrlObsolete = “http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411” | Алгоритм подписи для XmlDsig, ГОСТ 2001. |
XmlDsigGost3411UrlObsolete = “http://www.w3.org/2001/04/xmldsig-more#gostr3411” | Алгоритм хеширования для XmlDsig, ГОСТ 2001. |
XmlDsigGost3410Url = “urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102001-gostr3411” | Алгоритм подписи для XmlDsig, ГОСТ 2001. |
XmlDsigGost3411Url = “urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr3411” | Алгоритм хеширования для XmlDsig, ГОСТ 2001. |
XmlDsigGost3410Url2021256 = “urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102021-gostr34112021-256” | Алгоритм подписи для XmlDsig, ГОСТ 2021 (256). |
XmlDsigGost3411Url2021256 = “urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112021-256” | Алгоритм хеширования для XmlDsig, ГОСТ 2021 (256). |
XmlDsigGost3410Url2021512 = “urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102021-gostr34112021-512” | Алгоритм подписи для XmlDsig, ГОСТ 2021 (512). |
XmlDsigGost3411Url2021512 = “urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112021-512” | Алгоритм хеширования для XmlDsig, ГОСТ 2021 (512). |
CADESCOM_CADES_DEFAULT = 0 | Тип подписи по умолчанию (CAdES-X Long Type 1). |
CADESCOM_CADES_BES = 1 | Тип подписи CAdES-BES. |
CADESCOM_CADES_T = 0x5 | Тип подписи CAdES-T. |
CADESCOM_CADES_X_LONG_TYPE_1 = 0x5d | Тип подписи CAdES-X Long Type 1. |
CADESCOM_PKCS7_TYPE = 0xffff | Тип подписи PKCS7. |
CADESCOM_ENCODE_BASE64 = 0 | Кодировка BASE64. |
CADESCOM_ENCODE_BINARY = 1 | Бинарные данные. |
CADESCOM_XADES_DEFAULT = 0x00000010 | Тип подписи по умолчанию (XAdES-X Long Type 1). |
CADESCOM_XADES_BES = 0x00000020 | Тип подписи XAdES-BES. |
CADESCOM_XADES_T = 0x00000050 | Тип подписи XAdES-T. |
CADESCOM_XADES_X_LONG_TYPE_1 = 0x000005d0 | Тип подписи XAdES-X Long Type 1. |
CADESCOM_XADES_A = 0x000007d0 | Тип подписи XAdES-A. |
CADESCOM_XMLDSIG_TYPE = 0 | Тип подписи XMLDSIG. |
CAPICOM_CERTIFICATE_INCLUDE_CHAIN_EXCEPT_ROOT = 0 | Сохраняет все сертификаты цепочки за исключением корневого. |
CAPICOM_CERTIFICATE_INCLUDE_WHOLE_CHAIN = 1 | Сохраняет полную цепочку. |
CAPICOM_CERT_INFO_SUBJECT_SIMPLE_NAME = 0 | Возвращает имя наименования сертификата. |
CAPICOM_CERT_INFO_ISSUER_SIMPLE_NAME = 1 | Возвращает имя издателя сертификата. |
CAPICOM_CERTIFICATE_FIND_SHA1_HASH = 0 | Возвращает сертификаты соответствующие указанному хэшу SHA1. |
CAPICOM_CERTIFICATE_FIND_SUBJECT_NAME = 1 | Возвращает сертификаты, наименование которого точно или частично совпадает с указанным. |
CAPICOM_CERTIFICATE_FIND_ISSUER_NAME = 2 | Возвращает сертификаты, наименование издателя которого точно или частично совпадает с указанным. |
CAPICOM_CERTIFICATE_FIND_ROOT_NAME = 3 | Возвращает сертификаты, у которых наименование корневого точно или частично совпадает с указанным. |
CAPICOM_CERTIFICATE_FIND_TEMPLATE_NAME = 4 | Возвращает сертификаты, у которых шаблонное имя точно или частично совпадает с указанным. |
CAPICOM_CERTIFICATE_FIND_EXTENSION = 5 | Возвращает сертификаты, у которых имеется раcширение, совпадающее с указанным. |
CAPICOM_CERTIFICATE_FIND_EXTENDED_PROPERTY = 6 | Возвращает сертификаты, у которых идентификатор раcширенного свойства совпадает с указанным. |
CAPICOM_CERTIFICATE_FIND_CERTIFICATE_POLICY = 8 | Возвращает сертификаты, содержащие указанный OID политики. |
CAPICOM_CERTIFICATE_FIND_TIME_VALID = 9 | Возвращает действующие на текущее время сертификаты. |
CAPICOM_CERTIFICATE_FIND_TIME_NOT_YET_VALID = 10 | Возвращает сертификаты, время которых невалидно. |
CAPICOM_CERTIFICATE_FIND_TIME_EXPIRED = 11 | Возвращает просроченные сертификаты. |
CAPICOM_CERTIFICATE_FIND_KEY_USAGE = 12 | Возвращает сертификаты, содержащие ключи, которые могут быть использованны указанным способом. |
CAPICOM_DIGITAL_SIGNATURE_KEY_USAGE = 128 | Ключ может быть использован для создания цифровой подписи. |
CAPICOM_PROPID_ENHKEY_USAGE = 9 | EKU. |
CAPICOM_OID_OTHER = 0 | Объект не соответствует ни одному из предуставленных типов. |
CAPICOM_OID_KEY_USAGE_EXTENSION = 10 | Расширение сертификата, содержащее информацию о назначении открытого ключа. |
CAPICOM_EKU_OTHER = 0 | Сертификат может быть использован для чего-то, что не предустановлено. |
CAPICOM_EKU_SERVER_AUTH = 1 | Сертификат может быть использован для аутентификации сервера. |
CAPICOM_EKU_CLIENT_AUTH = 2 | Сертификат может быть использован для аутентификации клиента. |
CAPICOM_EKU_CODE_SIGNING = 3 | Сертификат может быть использован для создания цифровой подписи. |
CAPICOM_EKU_EMAIL_PROTECTION = 4 | Сертификат может быть использован для защиты электронной подписи. |
CAPICOM_EKU_SMARTCARD_LOGON = 5 | Сертификат может быть использован для входа со смарт карты. |
CAPICOM_AUTHENTICATED_ATTRIBUTE_SIGNING_TIME = 0 | Время подписи. Совпадает с CADESCOM_AUTHENTICATED_ATTRIBUTE_SIGNING_TIME |
CAPICOM_AUTHENTICATED_ATTRIBUTE_DOCUMENT_NAME = 1 | Название документа. Совпадает с CADESCOM_AUTHENTICATED_ATTRIBUTE_DOCUMENT_NAME |
CAPICOM_AUTHENTICATED_ATTRIBUTE_DOCUMENT_DESCRIPTION = 2 | Описание документа. Совпадает с CADESCOM_AUTHENTICATED_ATTRIBUTE_DOCUMENT_DESCRIPTION |
CADESCOM_AUTHENTICATED_ATTRIBUTE_SIGNING_TIME = 0 | Время подписи. |
CADESCOM_AUTHENTICATED_ATTRIBUTE_DOCUMENT_NAME = 1 | Название документа. |
CADESCOM_AUTHENTICATED_ATTRIBUTE_DOCUMENT_DESCRIPTION = 2 | Описание документа. |
CADESCOM_ATTRIBUTE_OTHER = -1 | Прочие атрибуты. |
CADESCOM_DISPLAY_DATA_NONE = 0 | Данные не будут пересылаться в устройство. |
CADESCOM_DISPLAY_DATA_CONTENT = 1 | Отображаемые данные лежат в теле сообщения. |
CADESCOM_DISPLAY_DATA_ATTRIBUTE = 2 | Отображаемые данные лежат в подписанном атрибуте сообщения. |
CADESCOM_ENCRYPTION_ALGORITHM_RC2 = 0 | Алгоритм RSA RC2. |
CADESCOM_ENCRYPTION_ALGORITHM_RC4 = 1 | Алгоритм RSA RC4. |
CADESCOM_ENCRYPTION_ALGORITHM_DES = 2 | Алгоритм DES. |
CADESCOM_ENCRYPTION_ALGORITHM_3DES = 3 | Алгоритм 3DES. |
CADESCOM_ENCRYPTION_ALGORITHM_AES = 4 | Алгоритм AES. |
CADESCOM_ENCRYPTION_ALGORITHM_GOST_28147_89 = 25 | Алгоритм ГОСТ 28147-89. |
CADESCOM_HASH_ALGORITHM_SHA1 = 0 | Алгоритм SHA1. |
CADESCOM_HASH_ALGORITHM_MD2 = 1 | Алгоритм MD2. |
CADESCOM_HASH_ALGORITHM_MD4 = 2 | Алгоритм MD4. |
CADESCOM_HASH_ALGORITHM_MD5 = 3 | Алгоритм MD5. |
CADESCOM_HASH_ALGORITHM_SHA_256 = 4 | Алгоритм SHA1 с длиной ключа 256 бит. |
CADESCOM_HASH_ALGORITHM_SHA_384 = 5 | Алгоритм SHA1 с длиной ключа 384 бита. |
CADESCOM_HASH_ALGORITHM_SHA_512 = 6 | Алгоритм SHA1 с длиной ключа 512 бит. |
CADESCOM_HASH_ALGORITHM_CP_GOST_3411 = 100 | Алгоритм ГОСТ Р 34.11-94. |
CADESCOM_HASH_ALGORITHM_CP_GOST_3411_2021_256 = 101 | Алгоритм ГОСТ Р 34.11-2021. |
CADESCOM_HASH_ALGORITHM_CP_GOST_3411_2021_512 = 102 | Алгоритм ГОСТ Р 34.11-2021. |
CADESCOM_HASH_ALGORITHM_CP_GOST_3411_HMAC = 110 | Алгоритм ГОСТ Р 34.11-94 HMAC. |
CADESCOM_HASH_ALGORITHM_CP_GOST_3411_2021_256_HMAC = 111 | Алгоритм ГОСТ Р 34.11-2021 HMAC. |
CADESCOM_HASH_ALGORITHM_CP_GOST_3411_2021_512_HMAC = 112 | Алгоритм ГОСТ Р 34.11-2021 HMAC. |
LOG_LEVEL_DEBUG = 4 | Уровень ведения логов DEBUG. |
LOG_LEVEL_INFO = 2 | Уровень ведения логов INFO. |
LOG_LEVEL_ERROR = 1 | Уровень ведения логов ERROR. |
CADESCOM_AllowNone = 0x00 | Флаг запрета установки недоверенных сертификатов или сертификатов, для которых нет соответствующего запроса. |
CADESCOM_AllowNoOutstandingRequest = 0x01 | Флаг создания закрытого ключа из ответа на запрос. |
CADESCOM_AllowUntrustedCertificate = 0x02 | Флаг установки недоверенных сертификатов конечного пользователя и центров сертификации. |
CADESCOM_AllowUntrustedRoot = 0x04 | Флаг установки сертификата, даже если корневой центр сертификации для него не является доверенным. |
CADESCOM_SkipInstallToStore = 0x10000000 | Флаг пропуска установки сертификата в хранилище сертификатов. |
ENABLE_CARRIER_TYPE_CSP = 0x01 | Обычный криптоконтейнер (HDIMAGE, REGISTRY). |
ENABLE_CARRIER_TYPE_FKC_NO_SM = 0x02 | ФКН без SM. |
ENABLE_CARRIER_TYPE_FKC_SM = 0x04 | ФКН с SM. |
ENABLE_ANY_CARRIER_TYPE = 0x07 | ENABLE_CARRIER_TYPE_CSP | ENABLE_CARRIER_TYPE_FKC_NO_SM | ENABLE_CARRIER_TYPE_FKC_SM. |
DISABLE_EVERY_CARRIER_OPERATION = 0x00 | Запрещенные виды носителей полностью запрещены. |
ENABLE_CARRIER_OPEN_ENUM = 0x01 | На запрещенных видах носителей можно открывать и перечислять контейнеры. |
ENABLE_CARRIER_CREATE = 0x02 | На запрещенных видах носителей можно создавать контейнеры. |
ENABLE_ANY_OPERATION = 0x03 | ENABLE_CARRIER_OPEN_ENUM | ENABLE_CARRIER_CREATE. |
MEDIA_TYPE_REGISTRY = 0x00000001 | Реестр. |
MEDIA_TYPE_HDIMAGE = 0x00000002 | Жесткий диск. |
MEDIA_TYPE_CLOUD = 0x00000004 | Облачный носитель. |
MEDIA_TYPE_SCARD = 0x00000008 | Смарт-карта или любое другое устройство с интерфейсом смарт-карты. |
XCN_CRYPT_STRING_BASE64HEADER = 0 | Кодировка base64 с использованием открывающего и закрывающего заголовков сертификата. |
AT_KEYEXCHANGE = 1 | Использование ключа для подписывания и шифрования. |
AT_SIGNATURE = 2 | Использование ключа только для подписывания. |
Обьект cadesplugin при инициализации может использовать константы у обьекта window.
Название свойства обьекта window | Назначение |
---|---|
cadesplugin_load_timeout | Таймаут для ожидания загрузки плагина КриптоПро ЭЦП Browser plug-in в мс. По умолчанию 20000. |
Перечень вызовов и методов, использование которых при разработке систем на основе ПО «КриптоПро ЭЦП Browser plug-in» версия 2.0, может привести к необходимости дополнительных тематических исследований:
- использование объекта CPHashedData для вычисления HMAC с помощью вызова метода Hash при выборе пользователем идентификатора алгоритма ключевого хэширования (CADESCOM_HASH_ALGORITHM_CP_GOST_3411_HMAC, CADESCOM_HASH_ALGORITHM_CP_GOST_3411_2021_256_HMAC, CADESCOM_HASH_ALGORITHM_CP_GOST_3411_2021_512_HMAC)
- установка значения хеша для объекта CPHashedData с помощью вызова метода SetHashValue
- вызовы метода SignHash и VerifyHash обьекта RawSignature для создании ЭП
- вызовы метода CoSignHash, SignHash и VerifyHash обьекта SignedData для создании ЭП
- использование обьекта SymmetricAlgorithm
В системах, требующих контроля поддерживаемых криптопровайдеров, рекомендуется устанавливать параметр ProviderTypeStrictMode ветки реестра “HKLM\Software\Crypto Pro\CAdES” типа DWORD (“\config\CAdES\ProviderTypeStrictMode” типа long для Unix платформ) в значение 1, предназначенный для проверки соответствия используемого типа криптопровайдера одному из типов криптопровайдера, поддерживаемых СКЗИ «КриптоПро CSP» (PROV_GOST_2001_DH, PROV_GOST_2021_256, PROV_GOST_2021_512).
Стандартный пароль эцп — где его взять?
При работе с Электронной подписью, будь то подписание заявки, копирование подписи или другое действие связанное с использование сертификата Электронной подписи, у пользователя запрашивается пин-код (пароль) от подписи. Владельцу Электронной подписи требуется ввести стандартный пароль ЭЦП. Окно с запросом ввести пин-код отображается в течении 10 минут, после чего, если не был введён пин-код окно закрывается.
На каждый носитель для электронной подписи, будь то Etoken (Jacarta) или RuToken устанавливается пароль по умолчанию. Также пароль могут называть «пин-кодом». Когда пользователь совершает какое либо действие с электронной подписью (авторизация на площадке по ЭП или подписание заявки) — происходит обращение к ЭЦП и у пользователя запрашивает пин-код (пароль).
Электронная подпись документов word
Рассмотрим подписание документов WORD на пример MS Office 2020. Для того, чтобы подписать документ в формате WORD требуется:
- Открыть «Файл» — «Сведения» — «Защита документа» — «Добавить цифровую подпись»;
- MS WORD предложит выбрать тип подтверждения, доступно три варианта:
- Создал и утвердил данный документ;
- Создал данный документ;
- Утвердил данный документ.
- Указать произвольную цель подписания документа. Задаётся по усмотрению пользователя.
- Если на компьютере установлено несколько сертификатов элетронной подписи, то при помощи кнопки «Изменить» выбирается тот сертификат, которым нужно подписать документ.
- Нажать на кнопку «Подписать».
- Если вы увидели ошибку: «алгоритм шифрования необходимый для выполнения этой операции не установлен на этом компьютере«, значит у вас не установлен плагин КриптоПро Office Signature 2.0 . Установите данный плагин и повторите попдисание документа.
Как мы видим, при наличии установленного плагина КриптоПро Office Signature 2.0. и корректной работы ЭЦП, подписать электронной подписью документы WORD не представляет труда.
Как поставить Электронную подпись в pdf документе в Adobe Acrobat?