Obtaining an OUKEP and using it in the Honest Sign systems (GIS-MT, MDLP)

The article was written in collaboration with Linux administrator engineer Ivan Sinelobov.

1.Introduction

The essence of the problem: fresh law 443-FZthe electronic signature for signing electronic documents is issued only to the director who represents the interests of the company without a power of attorney.

The key is non-copyable, it is impossible to make a duplicate for the chief accountant, lawyer or tender specialist. It is also impossible to extract it and use it in any automated systems. For example, such an EDS cannot be used to automatically sign messages transmitted to the national operator of digital marking of goods “Honest Sign”. Such measures are taken by the state to ensure business security.

In a very good article on the popular resource for accountants klerk.ru there is an article [1] about how this problem is solved by switching to individual certificates (UCEP) and machine-readable powers of attorney (MRA).

But the deadline, which is August 31, 2024, is coming soon, and as it turns out, the scheme with the enhanced electronic signature of an individual with the International Blacklist, which will be used in automated signature and exchange systems via API, is not applicable to all market participants.

What to do? One of the possible solutions is to obtain a qualified certificate of the electronic signature verification key (QSKPEP) of the Information System Operator (anonymous FTS certificate) using a request file in PKCS#10 format.

2.Legal grounds.

Legal grounds that will allow the company's IT specialists and lawyers to speak the same language.

2.1. Federal Law “On Electronic Signature” dated 06.04.2011 N 63-FZ [2]

2.2. On approval of the Procedure for the implementation by the Federal Tax Service of the functions of an accredited certification center and the performance of its duties [3]

2.3.Issue of qualified certificates to operators of information systems (anonymous certificates) [4]

2.4. Trustees of the Federal Tax Service of Russia Certification Center [5]

2.5. “Anonymous” electronic signature: how to get it and where to use it [6]

2.6. Assigning a person responsible for the “depersonalized” signature [7]

2.7. Training Center “Foundation” [8]

2.8.TC “NTSSoft” [9]

3. List of required documents for submission to the Certification Authority.

Samples of the Letter and Order can be downloaded from the attached links from github [10, 11].

According to information from the Federal Tax Service of Russia [12]:

The Certification Authority of the Federal Tax Service of Russia issues impersonal certificates used exclusively for the automatic creation (verification) of an electronic signature in an electronic document.

To obtain an “impersonal” certificate, you must be a person acting on behalf of a legal entity without a power of attorney, or an individual entrepreneur, and present to the place of issue of the Certification Center of the Federal Tax Service of Russia:

A letter on official letterhead with an attached copy of the administrative document on the creation of the information system, or another document on the basis of which the given legal entity or individual entrepreneur performs the functions of the operator of the information system.

The main document certifying the identity of the applicant (passport).

Information about the insurance number of the individual personal account.

Information about the taxpayer identification number – legal entity and (or) individual.

Let's move on to IT activities.

4.Preparing the workplace.

While organizational issues are being resolved, you can begin preparing the workplace and checking the work with the test OUKEP.

To do this you need:

4.1. Prepare Rutoken

For testing purposes, you need to choose the same one that will be used in the production environment. For example, Rutoken Lite 1010 (in the photo):

Rutoken Lite 1010

Rutoken Lite 1010

4.3.Download and install the certified version of CryptoPro CSP 5 R3 [13]

Before downloading, you need to be authorized on the cryptorpo.ru website

4.4.Download the CryptoPro cryptcp program [14]

4.5. In the directory with the cryptcp.x64.exe program, save the files from github PersonalPresence.ext and

RemoteCertificate.ext [15, 16]

4.6. Run the command in the cli (representing one line), the template file can also be downloaded from github [17]

cryptcp.x64.exe -createrqst MY-REQ.req -rdn “CN=””LLC “”””MY-COMPANY”””””, E=MY-EMAIL, C=RU, S=””77 g . Moscow””, L=””MY-CITY””, STREET=””MY-STREET””, O=””LLC “”””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

INN (MY-INN-10char), OGRN (MY-OGRN-13char), Company name (MY-COMPANY), etc. are taken from the Unified State Register of Legal Entities even for tests [18]

Also note:

MY_IDENTIFICATION-KIND.ext, RemoteCertificate.ext – receiving without visiting the Federal Tax Service, our version for testing.

Generating a request:

CriptoPro CSP will offer a device to choose from for saving the container. As such a device, you can choose the already mentioned test Rutoken Lite 1010, which should be inserted into the USB port of the computer on which the certificate is being generated.

Generation:

Results:

5. Selecting a test certification authority (CA)

The choice of a test CA is determined by the purpose of testing.

For example, for exchange with “Honest sign. MDLP” the test certificate issued in Crypto-Pro cannot be used. Error:

and vice versa, an attempt to load a test certificate working in MDLP in “Honest Sign. GIS-MT” ends with an error:

5.1. Test CA Crypto-Pro [19]

5.2. Test Certification Center Infotex [20]

5.3. TrueMark Test Certification Authority [21]

6.Generating a test certificate

Generating a certificate in a test CA from a PKCS#10 file using the Infotex CA as an example

The server generated a certificate based on the request file:

7. “Forwarding” the token to the automatic signature server.

In the modern landscape, when virtualization systems have become widespread, such a virtualized server will most likely also be a machine working with electronic signatures.

In order to “forward” a USB token with an OUKEP in a virtualized environment, you can use a hardware and software complex that allows you to organize remote access to USB devices via a local network or the Internet. For example, Digi AnywhereUSB or an analogue of the Russian manufacturer NIO-EUSB [22] (in the photo):

Let's look at the latter in a little more detail.

Let's assume that in our case the host for the API exchange client will be a Linux machine.

7.1. From the manufacturer's website [23] download the client suitable for your OS

7.2 The client can be launched via cli or as a service (preferred method)

If the client is running as a service, the configuration file /etc/rhcl has the following structure:

Where ManualHubs is

Parameters for section [AutoShare] can be obtained by the command ./ruclientx86_64 -t “LIST”

7.3. As a result, we should get:

Output of lsusb command:

Output of the command ./ruclientx86_64 -t “LIST”:

Where niousb: XXX

Rutoken lite (niousb.XXX)

8. Registration of OUKEP in automated systems

Registration of OUKEP in automated systems has its own characteristics.

Let's look at them using examples from the “Honest Sign” systems:

  • State information system for monitoring the turnover of goods (GIS MT) [24].

  • Monitoring the Movement of Medicines (MDM) [25].

8.1. Registration of the OUKEP using the example of GIS-MT
General view of the interface (screenshot):

In the menu we select:

Profile – Users – Employees – Add user – Upload certificate – Select the public part of the certificate that we made in section 6 (screenshot):

8.2. Registration of the OUKEP using the MDLP example:

In the Personal Account of MDLP, select: Administration – Accounting systems – Add an accounting system (screenshot):

Let's go to the created accounting system:

Add the public part of the certificate that we made in section 6 (screenshot):

9. Conclusion.

This article presents possible solutions for cases when the use of an UCEP with a MCHD in a company is not applicable. Examples of generating an UCEP and recording it on a storage medium (Rutoken), as well as using Rutoken in environments with a virtualized environment, as well as its registration in systems such as GIS-MT and MDLP are given.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *