Статья написана в соавторстве с инженером-Linux-администратором -  Иваном Синелобовым.

1.Введение

Cуть проблемы: по свежему закону 443-ФЗ, КЭП для подписания электронных документов оформляется только на директора, который представляет интересы компании без доверенности.

Ключ некопируемый, с него невозможно сделать дубликат для главбуха, юриста или специалиста по тендерам. Невозможно его также извлечь и использовать в каких-либо автоматизированных системах. Например, такой КЭП нельзя использовать для автоматической подписи сообщений передаваемых национальному оператору цифровой маркировки товаров "Честный знак". Такие меры предприняты государством для обеспечения безопасности бизнеса.

В очень хорошей статье на популярном ресурсе для бухгалтеров  klerk.ru есть статья [1] о том как данная проблема решается переходом на сертификаты физического лица (УКЭП) и машиночитаемые доверенности (МЧД). 

Но дедлайн, а он 31 августа 2024 года, уже скоро, а как выяснилось не для всех участников рынка применима схема с УКЭП физического лица с МЧД, который будет использоваться в автоматизированных системах подписи и обмена по API.

Что же делать? Одним из возможных выходов - это получение квалифицированного сертификата ключа проверки электронной подписи (КСКПЭП) Оператора информационной системы (обезличенного сертификата ФНС) по файлу запроса в формате PKCS#10.

2.Юридические основания.

Юридические основания, которые позволят ИТ-шникам и юристам компании разговаривать на одном языке.

2.1.Федеральный закон "Об электронной подписи" от 06.04.2011 N 63-ФЗ [2]

2.2.Об утверждении Порядка реализации Федеральной налоговой службой функций аккредитованного удостоверяющего центра и исполнения его обязанностей [3]

2.3.Выдача квалифицированных сертификатов Операторам информационных систем (обезличенных сертификатов) [4]

2.4.Доверенные лица УЦ ФНС России [5]

2.5.«Обезличенная» электронная подпись: как её получить и где использовать [6]

2.6. Назначение ответственного за «обезличенную» подпись [7]

2.7.УЦ «Основание» [8]

2.8.УЦ «НТССофт» [9]

3.Список необходимых документов для подачи в УЦ.

Образцы Письма и Приказа можно загрузить по приложенным ссылкам с github [10, 11].

Согласно информации от ФНС России [12]:

Удостоверяющий центр ФНС России выдает обезличенные сертификаты, применяемые исключительно для автоматического создания (проверки) электронной подписи в электронном документе.

Для получения «обезличенного» сертификата необходимо являться лицом, действующим от имени юридического лица без доверенности, или индивидуальным предпринимателем и представить в место выдачи Удостоверяющего центра ФНС России:

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

Основной документ, удостоверяющий личность заявителя (паспорт).

Сведения о страховом номере индивидуального лицевого счета.

Сведения об идентификационном номере налогоплательщика – юридического лица и (или) физического лица.

Перейдём к IT-активностям.

4.Подготовка рабочего места.

Пока решаются организационные вопросы можно приступить к подготовке рабочего места и проверки работы с тестовым ОУКЭП.

Для этого необходимо:

4.1. Подготовить Rutoken

Для тестовых целей необходимо выбирать такой же, какой будет использован и в продуктивной среде. Например, Рутокен Lite 1010 (на фото):

4.3.Скачать и установить сертифицированную версию КриптоПро CSP 5 R3 [13]

Перед загрузкой нужно быть авторизованным на сайте cryptorpo.ru

4.4.Скачать программу КриптоПро cryptcp [14]

4.5.В каталог c программой cryptcp.x64.exe сохранить файлы с github PersonalPresence.ext и

RemoteCertificate.ext [15, 16]

4.6.Выполнить в cli команду (представляющую одну строку), файл-шаблон загрузить можно также с github [17]

cryptcp.x64.exe -createrqst MY-REQ.req -rdn "CN=""ООО """"MY-COMPANY"""""", E=MY-EMAIL, C=RU, S=""77 г. Москва"", L=""MY-CITY"", STREET=""MY-STREET"", O=""ООО """"MY-COMPANY"""""", 1.2.643.100.4=MY-INN-10char, 1.2.643.100.1=MY-OGRN-13char" -pin MY-CONTAINER-PASSWORD -provtype 80 -provname "Crypto-Pro GOST R 34.10-2012 Cryptographic Service Provider" -certusage 1.3.6.1.5.5.7.3.2 -ext MY_IDENTIFICATION-KIND.ext

ИНН (MY-INN-10char), ОГРН(MY-OGRN-13char), Название компании (MY-COMPANY) и т.д берутся из ЕГРЮЛ даже для тестов [18]

также обратите внимание на:

MY_IDENTIFICATION-KIND.ext, RemoteCertificate.ext - получение без визита в ФНС, наш вариант для тестов.

Генерация запроса:

CriptoPro CSP предложит устройство на выбор для сохранения контейнера. В качестве такого устройства можно выбирать уже упоминавшийся тестовый Rutoken Lite 1010 , который должен быть к этому моменту вставлен в USB-порт компьютера, на котором происходит генерация сертификата.

Генерация:

Результаты:

5.Выбор тестового удостоверяющий центра (УЦ)

Выбор тестового УЦ определяется целью тестирования.

Так, например, для обмена с "Честный знак. МДЛП" тестовый сертификат выданный в Крипто-Про использовать не получиться. Ошибка:

и наоборот, попытка загрузить тестовый сертификат, работающий в МДЛП в "Честный знак. ГИС-МТ" заканчивается ошибкой:

5.1. Тестовый УЦ Крипто-Про [19]

5.2. Тестовый УЦ Инфотекс [20]

5.3. Тестовый УЦ TrueMark [21]

6.Генерация тестового сертификата

Генерация сертификата в тестовом УЦ из файла PKCS#10 на примере УЦ Инфотекс

Сервер сгенерировал сертификат по файлу запроса:

7."Проброс" токена на сервер автоматической подписи.

В современном ландшафте, когда системы виртуализации получили широкое распространение, таким виртуализированным сервером скорее всего будет и машина работающая с электронными подписями.

Для того, чтобы "пробросить" USB-токен с ОУКЭП в виртуализованном окружении можно использовать программно-аппаратный комплекс позволяющий организовать удаленный доступ к USB устройствам через локальную сеть или Internet. Например, Digi AnywhereUSB или аналог  российского производителя NIO-EUSB [22] (на фото):

Давайте рассмотрим последнюю чуть более подробно.

Предположим, что в нашем случае хостом для клиента обмена по API будет выступать Linux-машина.

7.1. С сайта производителя [23] скачиваем подходящий для Вашей ОС клиент

7.2. Клиент может быть запущен через cli или в виде службы (более предпочтительный способ)

    В случае запуска клиента в виде службы конфигурационный файл /etc/rhcl имеет следующую структуру:

Где ManualHubs - <адрес:порт USB-хаба в Вашей сети>

Параметры для секции [AutoShare] можно получить командой ./ruclientx86_64 -t "LIST"

7.3. В итоге у нас должно получиться:

Вывод команды lsusb:

Вывод команды ./ruclientx86_64 -t "LIST":

Где niousb: XXX <XXX - номер порта USB-hub-а>

Rutoken lite (niousb.XXX) <XXX - номер USB в который вставлен Рутокен>

8.Регистрация ОУКЭП в автоматизированных системах

Регистрация ОУКЭП в автоматизированных системах имеет свои особенности.

Разберём их на примерах систем "Честного знака":

• Государственная информационная система мониторинга оборота товаров (ГИС МТ) [24].

• Мониторинг Движения Лекарственных Препаратов (МДЛП) [25].

8.1. Регистрация ОУКЭП на примере ГИС-МТ
Общий вид интерфейса (скриншот):

В меню выбираем:

Профиль - Пользователи - Сотрудники  - Добавление пользователя - Загрузить сертификат - Выбираем открытую часть сертификата, который мы сделали в разделе 6 (скриншот):

8.2. Регистрация ОУКЭП на примере МДЛП:

В Личном Кабинете МДЛП выбираем: Администрирование - Учётные системы - Добавить учётную систему (скриншот):

Переходим в созданную учётную систему:

Добавляем открытую часть сертификата, который мы сделали в разделе 6 (скриншот):

9.Заключение.

В данной статье представлены варианта решения на случай, когда использование УКЭП с МЧД в компании оказывается не применимым. Приведены примеры генерации ОУКЭП и его записи на носитель (Рутокен), а также использования Рутокен в средах с виртуализованным окружением, а также его регистрации в таких системах как ГИС-МТ и МДЛП.