Problems of reporting electronically from 1C 8.3 to GNU / Linux

Hello Gictimes, today we’ll talk about some, and in fact - one big, problems of electronic reporting in the GNU / Linux system.

The issue of submitting electronic reporting from the Linux OS has long been discussed both at Habré / Giktayms, and at thematic forums - Mista, Ubuntu, LOR, CryptoPro and the forum of technical support 1C: ITS. In a nutshell, at the moment there are two solutions - either use a cloud-based CEP and submit reports via a browser, or use a dedicated / virtual machine with Windows (even a trial version) installed to submit reports. The option of reporting using specialized utilities provided by the authorities (Federal Tax Service, PFR, FSS, Rosstat, FSRAR) is possible only when using Wine @ Etersoft, which is actually also a crutch (because we need TWO licenses for CryptoPro CIPI for Windows and Linux).

It is no secret that there are not so many programs for GNU / Linux for bookkeeping: Pineapple (which now rests in peace), Ukrainian Debit + (for which the Russian legislation support module has not been updated, Ktulu knows how much) and 1C accounting . This refers to Native applications. Of all the above, only 1C at the time of writing is included in the state register of domestic software and contains mechanisms for preparing and submitting reports in electronic form through special operators of electronic document management. By the way, there are not many operators supported by 1C accounting: ZAO Kaluga-Astral (developer of the 1C-Reporting subsystem), OOO Takskom, OOO NPF Forum and the mythical “Other document management operator”.
Unfortunately, reporting from 1C is fraught with a number of difficulties that an ordinary (and experienced) system administrator may encounter. Of course, we will consider these problems in detail and how to solve them.

The first problem we are facing is cryptographic information protection. No, not their absence, they are. For Linux, there are several certified cryptographic information protection tools (with GOST support) available for installation and used in different subsystems. At the time of this writing, these are the following cryptocurrencies, correct me if I missed something:

• CryptoCom
  This cryptographic information protection tool is available for the i686 and amd64 platforms, it is used mainly in Internet banking systems, in particular, the iBank system (used by many banks, such as Gazprombank, UBIRIR, Alpha, etc.).

  
  

• Lissi CSP
  One of the existing cryptographic information protection tools, which provides, besides directly, cryptographic information protection tools, versions of the Mozilla Firefox browser and the Mozilla Thunderbird email client with support for encryption algorithms and digital signature of the GOST family. Unfortunately, it only supports the i686 platform, with the ruToken driver, CIPF compatibility could not be verified, although the manufacturer claims it. However, the extension for Mozilla products regularly sees certificates and allows for the signature, encryption and two-way authentication of HTTPS using GOST algorithms. I have not tested compatibility with 1C.
  Nevertheless, the product is very worthy if you use the 32-bit version of the system. It is worth remembering that in this case no application will be able to allocate more than 3 GB of memory per process. Some applications, such as a DBMS, can do the trick with shmem and use up to 64 GB of memory due to the allocation of one process for each session, but 1C accounting does not use such technology and I would not recommend installing a server on a 32-bit architecture with this cryptographic information protection.

  
  

• CryptoPro CSP
  In fact, the only complete Linux solution for working with electronic signature and encryption at the moment. Available for platforms i686, amd64, armhf (including android), PowerPC. This is not to mention the fact that they have versions for Solaris (i686, amd64, sparc), AIX, FreeBSD, OSX and iOS. Oddly enough (sarcasm), it is CryptoPro that is officially recommended by many public authorities for interaction and electronic document management. CryptoPro licenses often come as part of an EDS key, and as part of an integrated service agreement for reporting. My choice was unequivocal in favor of this ccci. The disadvantages include the relative complexity of the installation on systems other than RHEL / SLES and the encountered shortcomings in the assembly of software packages (unauthorized imported characters and exported functions with broken dependencies). In most cases, these shortcomings are not visible to the user, because These functions are designed for the operation of various libraries within CryptoPro and are automatically resolved upon their first call by the OS kernel (the necessary libraries are already loaded in the application address space). The second minus is the lack of an email client, if the CryptoFox browser is presented, but they refused to support Thunderbird in CryptoPro. We must pay tribute to the fact that they made active attempts to make changes to the working version of NSS in order to support GOST, but it is still there. If the changes were accepted, GOST support would appear in all browsers and applications using NSS, such as Open / LibreOffice, Mozilla, Nautilus / Nemo, Thunar, XCA and other programs. These functions are designed for the operation of various libraries within CryptoPro and are automatically resolved upon their first call by the OS kernel (the necessary libraries are already loaded in the application address space). The second minus is the lack of an email client, if the CryptoFox browser is presented, but they refused to support Thunderbird in CryptoPro. We must pay tribute to the fact that they made active attempts to make changes to the working version of NSS in order to support GOST, but it is still there. If the changes were accepted, GOST support would appear in all browsers and applications using NSS, such as Open / LibreOffice, Mozilla, Nautilus / Nemo, Thunar, XCA and other programs. These functions are designed for the operation of various libraries within CryptoPro and are automatically resolved upon their first call by the OS kernel (the necessary libraries are already loaded in the application address space). The second minus is the lack of an email client, if the CryptoFox browser is presented, but they refused to support Thunderbird in CryptoPro. We must pay tribute to the fact that they made active attempts to make changes to the working version of NSS in order to support GOST, but it is still there. If the changes were accepted, GOST support would appear in all browsers and applications using NSS, such as Open / LibreOffice, Mozilla, Nautilus / Nemo, Thunar, XCA and other programs.

  
  
• VipNet
  Another certified CIPF, the support of which is initially present in 1C. Exists in beta for i686 and amd64 architectures. Unfortunately, besides the CIPF itself, they no longer have any products for Linux and full-fledged work on portals and trading platforms with it is impossible.

For obvious reasons, CryptoPro CIP was chosen, and let's dwell on it in more detail.

Firstly, for the Linux platform, there is no CryptoARM application familiar to many for signing documents. However, to create an attached and detached signature, you can use command line utilities. To create and verify the detached digital signature, I created two scripts - sign and verify, respectively. The text of the scripts is given below, I agree that they are somewhat crutal, but they were written in haste, and at that time the beta version of CryptoPro 4.0 was behaving strangely, with direct transfer of paths to signed and output files.

#!/bin/sh
DIR=`dirname $1`
/opt/cprocsp/bin/amd64/cryptcp -signf $2 $3 -cert -der -norev "$1"
mv "$1.sgn" "$1.p7s"

#!/bin/sh
DIR=`dirname $1`
cp "$1.p7s" "$1.sgn"
/opt/cprocsp/bin/amd64/cryptcp -vsignf -der -norev "$1"
rm "$1.sgn"

Secondly, and this is very important, we have the following picture. in 1C accounting, the standard settings for working with CryptoPro cryptographic information protection system are given for version 3.6. Version 3.6 runs the old version of CryptoFox. On this, the virtues end and a headache begins. The old version of CryptoFox does not display any modern site, even the portal of the tax office creeps out somewhere. When trying to install~ fresh~ the current version of CryptoFox 31, it crashes (Segmentation fault) when entering any site requiring HTTPS with the GOST algorithm. Sometimes it crashes even when the CryptoPro Browser Plugin plugin works. By the way, it’s also a very old version that supports only signature, but not encryption and works only with NPAPI.

With version 3.9, the situation is even more fun - 1C no longer sees it, but CryptoFox is still falling, with both old and new.

Version 4.0, on the contrary, does not appear to be 1C, but CryptoPro Browser Plugin 2.0 starts up with it, the entrance to the government sites from CryptoFox works (there is a separate discussion about them, and if you disassemble the work from GNU / Linux with them, there is enough material for one more article) . The problem is to get 1 SKU installed to cryptographic information protection. The problem, in general, is not so serious, it can be solved in just fifteen seconds, but it took a whole week to find the solution with the technical support of CryptoPro (and pushing me with 1C support to instructions in ITS). As a result, the problem was solved independently, and the solution was eventually published on the CryptoPro forum. Future problem solving methodology:

• In 1C accounting, it is possible to add an arbitrary cryptographic provider. We use this mechanism, add a new cryptographic provider, and name it, say "CryptoPro CSP 4.0".

  
  
• In order to get the name of the crypto provider and its type, we need to turn to the CryptoPro utility. The easiest way to get this data is by listing the installed certificates:

/opt/cprocsp/bin/amd64/certmgr -l

• We indicate the following data:
  

  Program name	Crypto-Pro GOST R 34.10-2001 KC1 CSP
  Type of program	75
  Signature algorithm	GOST R 34.10-2001
  Hash algorithm	GOST R 34.11-94
  Encryption algorithm	GOST 28147-89

• We save the cryptographic provider and specify the path to the library: /opt/cprocsp/lib/amd64/libcapi20.so

Done, 1C now sees the installed cryptographic provider. It would seem - everything, you can tread by adding certificates and setting up reporting, but it wasn’t here. Little white Siberian fox sneaked up to us from where we did not expect - from the developers themselves 1C. So historically, that the electronic document management subsystem, 1C-Reporting, the 1C core and configurations are written by different people, and even different companies. When creating configurations with the 1C-Reporting function for 1C 8.3, for example, "Enterprise Accounting 3.0", the developers without hesitation transferred the entire EDCO subsystem "as is", without changes, as a result of which we get a paradox. 1C accounting itself sees cryptographic information protection tools, sees certificates, allows you to install, sign and encrypt any documents, but at the same time, the electronic document management system (old version) does not see a single installed certificate at point-blank range, and accordingly cannot even get the initial configuration from the document management operator - there is simply nothing to decrypt it. Rather than deciphering, there is, but the EDCO subsystem uses its own mechanism for working with CIPF, using an external component (for Windows only) and does not know anything about the existence of built-in mechanisms for working with CIPF, which 1C itself uses as part of the configuration.

Nevertheless, the EDI subsystem (not to be confused with EDCO) with counterparties sees all the relevant certificates and allows you to connect to the electronic document management system. But not reporting.
For Linux, there is a restriction on the direct operation of the Client-EDI configuration with an external configuration database, and for this you need a working 1C server. Since the basic versions of the configurations do not allow using the client-server version of 1C deployment, integration of Client-EDI and accounting in Linux for such configurations is not possible, it will work only for fully functional ones. In most configurations, you can enable the exchange with counterparties, and it will work, despite the not working 1C-Reporting.

If we open the configurator and turn on debugging mode, we will see the following picture:
Forms 1C-Reporting use General-> GeneralModules-> Cryptography EDCO Client, which in turn relies on the work of the external Addin.EDOnative.CryptS component.
The same functionality for working with electronic digital signature and encryption (without the functionality of exchanging transport containers via electronic communication channels) is implemented in General-> GeneralModules-> Electronic SignatureCustomer, which takes into account work in the Linux family of OS and correctly loads both the external component of working with XMLDSig, so and crypto provider module. This library correctly sees all the certificates, allows you to sign and encrypt documents, contains functions for working with both objects in memory and files on the hard disk. This library is used in all standard mechanisms for working with digital signatures within 1C, except for the 1C-Reporting subsystem (EDCO).

That is, to implement the work of the 1C EDCO subsystem, it’s enough to rewrite either the 1C-Reporting form to use the built-in mechanisms, or to overload the EDCOKlient Cryptography to use not the external component, but forward calls to work with certificates, digital signatures and encryption to the built-in client for working with cryptographic information protection.
Communication with 1C technical support gave only the answer that they are aware of this problem, but there are too few clients using the GNU / Linux OS (the need is not widespread), but their task is “written down”.

UPD:
Taki managed to start the wizard after a detailed study of the source. While stuck on decrypting the container from Takskom, but certificates are already visible. It works only on the latest version of CryptoPro 4. Start as follows. The name of the presentation does not play a role, but “inside” 1C-EDCO exactly like this:

Required for verification are the fields Program name and Program type . The name of the program refers to the compatibility mode with the version of the cryptographic provider 2.0, in beta version 4.0 there was no name.

The main problem is hidden here: General-> General modules-> Cryptography EDCOM ServiceCustomer.GetCryptoproviders

ВходящиеПараметры = ПараметрыВМассив(1, ТолькоПоддерживаемые);

For Linux, remove one. Or add verification for CryptoPro version 3.9 and higher:
General-> General modules-> Cryptography EDCOCustomerServer.Get CryptoProviders.CryptoPro CryptoPro
Name: Crypto-Pro GOST R 34.10-2001 KC1 CSP
for the client, or
Name: Crypto-Pro GOST R 34.10-2001 KC2
for the server.