Problems of submitting reports in electronic form from 1C 8.3 in GNU / Linux

Hello Giktayms, today we will talk about some, and in fact - one big problem, the delivery of electronic reporting in the GNU / Linux system.

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

It’s no secret that for GNU / Linux OS there are not so many programs for bookkeeping: Pineapple (which now rests with the world), Ukrainian Debet + (whose Russian law support module has not been updated already, Ktulu knows how many) and 1C accounting . This refers to native applications. Of all the above, only 1C at the time of writing this article is included in the state register of domestic software and contains mechanisms for preparing and submitting reports in electronic form through special electronic document management operators. By the way, there are not many operators supported by 1C accounting: Kaluga-Astral, ZAO (developer of 1C-Reporting subsystem), Takskom, OOO Forus, LLC and the mythical “Other document management operator” LLC.
Unfortunately, the submission of reports from 1C is associated with a number of difficulties that an ordinary (and experienced) system administrator can face. Of course, we will consider in detail these problems and ways to solve them.

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

• CryptoCom
  This CRPD is available for the i686 and amd64 platforms, it is mainly used in Internet banking systems, in particular, the iBank system (used by many banks, such as GazpromBank, UBRIR, Alpha, etc.).

  
  

• Lissi csp
  One of the existing ICPDs provides, in addition to directly, ICPM, a version of the Mozilla Firefox browser and the Mozilla Thunderbird email client with support for encryption algorithms and electronic digital signatures of the GOST family. Unfortunately, it only supports the i686 platform, it was not possible to verify the compatibility of the CMIS with the ruToken driver, although the manufacturer claims it. However, the extension for Mozilla products regularly sees certificates and allows signature, encryption and two-way HTTPS authentication using GOST algorithms. Compatibility with 1C was not tested by me.
  Nevertheless, the product is very decent if you use the 32-bit version of the system. It is worth remembering that in this case no application can allocate more than 3 GB of memory per process. Some applications, such as a DBMS, can get by with the shmem trick and use up to 64 GB of memory by allocating one process for each session, but 1C accounting does not use this technology and I would not recommend installing a server with a 32-bit architecture with this SKZI.

  
  

• CryptoPro CSP
  In fact, the only currently comprehensive solution for Linux for working with electronic signature and encryption. 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. Strange as it may seem (sarcasm), it is CryptoPro that is officially recommended by many state bodies for interaction and electronic document circulation. Licenses for CryptoPro often come as part of an EDS key, and as part of an integrated service contract for reporting. My choice was clear in favor of this SKZI. The disadvantages include the relative complexity of installation on systems other than RHEL / SLES and encountered deficiencies in the assembly of software packages (not allowed imported symbols and exported functions with broken dependencies). In most cases, these shortcomings are not visible to the user, because These functions are intended for the operation of various libraries within CryptoPro and are automatically resolved when they are first called by the OS kernel (the necessary libraries are already loaded in the address space of the application). The second minus is the lack of an e-mail client, if the browser CryptoFox is present, but they refused to support Thunderbird in CryptoPro. We must pay tribute to the fact that they actively attempted to make changes to the working version of NSS in order to support GOST, but things are still there. If changes were adopted, GOST support would appear in all browsers and applications using NSS, such as Open / LibreOffice, Mozilla, Nautilus / Nemo, Thunar, XCA and other programs.

  
  
• VipNet
  One more certified SKZI which support is initially present in 1C. There is a beta version for i686 and amd64 architectures. Unfortunately, besides SKZI itself there are no other products for Linux and full-fledged work on portals and trading platforms with it is impossible.

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

First, 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 a detached digital signature, I created two scenarios - sign and verify, respectively. The text of the scenarios is given below, I agree that they are somewhat crutch, but it was written in haste, and at that time the beta version of CryptoPro 4.0 was behaving strangely, with a direct transfer of the paths to the 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, full-time settings for working with the CryptoPro IMSP are given for version 3.6. With version 3.6, the old version of CryptoFox works. At this point, the ends end and the headache begins. The old version of CryptoFox does not display any modern website, even the tax inspection portal crawls off somewhere. When trying to install ~ fresh ~ The current version of CryptoFox 31, it falls into the crust (Segmentation fault) when entering any site that requires HTTPS with the GOST algorithm. Sometimes it crashes even when the CryptoPro Browser Plugin is running. By the way, it is also a very old version that supports only the signature, but not encryption and works only with NPAPI.

With version 3.9, the situation is even more fun - 1C does not see it anymore, but CryptoFox is still falling, with both the old and the new.

Version 4.0, on the contrary, doesn’t see 1C, but CryptoPro Browser Plugin 2.0 starts with it, the entrance to the state site from CryptoFox works (there is a separate discussion about them, and if you analyze the work from the GNU / Linux OS with them, there’s enough material for another article) . The problem is to see the 1SK installed SKZI. The problem in general is not so serious, it is solved literally in fifteen seconds, but the whole week of communication with CryptoPro technical support was spent on finding the solution itself (and sending me 1C support to the ITS instruction). As a result, the problem was solved independently, and the solution was ultimately published on the CryptoPro forum. Methodology for solving problems for the future:

• In 1C accounting, you can add an arbitrary cryptographic provider. We will use this mechanism, add a new crypto-provider, and name it, say “CryptoPro CSP 4.0”.

  
  
• In order to get the name of the cryptographic provider and its type, we need to refer to the CryptoPro utility. The easiest way to obtain this data is to list 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 10.34-2001
  Hashing algorithm	GOST R 34.11-94
  Encryption algorithm	GOST 28147-89

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

Done, 1C now sees the established cryptographic provider. It would seem that everything can be shown to the addition of certificates and setting up the delivery of reports, but it was not there. Little white Siberian chanterelle crept up to us from where we did not expect - from the 1C developers themselves. So historically, the electronic document management subsystem, 1C-Reporting, 1C core and configuration 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, moved the entire EDCO subsystem "as is", without changes, as a result we get a paradox. 1C Accounting itself sees the CIPP, sees the certificates, allows them to install, sign and encrypt any documents, but the electronic document management system (the old version) does not see any installed certificates at all, and therefore cannot even get the initial configuration from the document operator - it simply has nothing to decipher. Rather than deciphering, there is, but the EDCO subsystem uses its own mechanism for working with IMSPs, using the external component (only for Windows) and does not know anything about the existence of built-in mechanisms for working with IISMs that 1C itself uses as part of its configuration.

However, the EDI subsystem (not to be confused with the EDCO) with counterparties sees all relevant certificates and allows you to connect to the electronic document management system. But not putting reports.
For Linux, there is a restriction on the direct operation of the Client-EHD configuration, with an external configuration base, 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 the 1C deployment, the 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 exchange with contractors, and it will work, despite not working 1C-Reporting.

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

That is, to implement the work of the 1C EDCO subsystem, it is enough to rewrite either the 1C-Reporting form to use the built-in mechanisms, or overload the Cryptography EDCOClient, to use not the external component, but to redirect the work calls with certificates, EDS and encryption to the embedded client of working with the CIPS.
Communication with technical support of 1C 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 massive), but the task is “recorded”.

UPD:
Taki managed to get the wizard to work after a detailed study of the sources. While stuck on the decryption of the container from Taxcom, but certificates are already seen. It works only on the latest version of CryptoPro 4. Start as shown below. The name of the presentation does not play a role, but “inside” 1C-EDKO exactly like this:

Required during verification are the Program Name and Program Type fields. The program name refers to the compatibility mode with the version of the crypto-provider 2.0, in the beta version 4.0 the name was absent.

The main problem is hidden here: General-> General Modules-> CryptographyEditor ServiceCustomer.Get Crypto Providers

  = (1, ); 

For Linux, remove the one. Or add a check for CryptoPro version 3.9 and higher:
General-> General Modules-> CryptographyEDCO Client Server. Get Crypto Provider. CryptoPro Crypto Provider
Name: Crypto-Pro GOST R 34.10-2001 KC1 CSP
for a customer or
Name: Crypto-Pro GOST R 34.10-2001 KC2 CSP
for the server.