Public Key Infrastructure: Certification Center based on the OpenSSL utility and SQLite3 (PostScript)

In a comment sent by garex , in response to the statement :

But today in the standard version of openssl there is no support for both GOST R 34.11-2012 and GOST R 34.10-2012. Moreover, in version 1.1, support for GOST cryptography is excluded from the standard delivery (“The GOST engine was removed”)

it was said:

What is not satisfied with this one , which is “removed?” Github.com/gost-engine/engine
Build example : github.com/rnixik/docker-openssl-gost/blob/master/Dockerfile

It was decided to test this version of openssl as part of CA CAFL63 . Using the specified build example, the openssl itself and the GOST engine were assembled and installed without any problems (everything was tested in the Linux environment and installed in the / usr / local / ssl directory). Naturally, to work with GOST-th cryptography (we are talking about GOST R 34.10-2012, GOST R 34.11-2012), you must register the connection of the gost.so engine in the configuration file openssl.cnf:

. . # OpenSSL default section [openssl_def] engines = engine_section # Engine scetion [engine_section] gost = gost_section # Engine gost section [gost_section] engine_id = gost dynamic_path = /usr/local/ssl/lib/engines-1.1/gost.so default_algorithms = ALL CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet . . . 

You can check the connection of the guest engine by running the following command:

 bash-4.3$ /usr/local/ssl/bin/openssl ciphers . . . GOST2012-GOST8912-GOST8912:GOST2001-GOST89-GOST89 . . . bash-4.3$ 

To view the supported GOST hash algorithms, just run the following command:

 bash-4.3$ /usr/local/ssl/bin/openssl list –digest-algorithms| grep md_gost md_gost12_256 md_gost12_512 md_gost94 bash-4.3$ 

As you can see, with the support of Russian cryptography in this version of openssl with the connected engine, everything is fine.

If you connect the openssl utility (Tools-> Settings-> System) in the previously created CA, then at first glance everything will work. You can view and requests and certificates. At the same time, all fields included in the DN (distinguished name) (TIN, OGRN, SNILS) are displayed correctly. But openssl refuses to remember extensions like issuerSignTool, subjectSignTool and others:



It should be noted that these extensions are an integral part of the SKPEP (qualified certificate of the electronic signature verification key), the requirements for which are approved by order of the FSB of December 27, 2011 N 795.

An analysis of the openssl utility has shown that it does not support the isserSignTool, objectSignTools and other extensions introduced by TC-26 for the SKPEP:

...
Error Loading request extension section v3_req
139974322407168: error: 22097081: X509 V3 routines: do_ext_nconf: unknown extension: crypto / x509v3 / v3_conf.c: 82:
139974322407168: error: 22098080: X509 V3 routines: X509V3_EXT_nconf: error in extension: crypto / x509v3 / v3_conf.c: 47: name = subjectSignTool, value = Name of the CMIS user
...
Error Loading request extension section v3_req
140154981721856: error: 22097081: X509 V3 routines: do_ext_nconf: unknown extension: crypto / x509v3 / v3_conf.c: 82:
140154981721856: error: 22098080: X509 V3 routines: X509V3_EXT_nconf: error in extension: crypto / x509v3 / v3_conf.c: 47: name = subjectSignTool, value = Name of CPMS user
...
Error Loading extension section cert_ext
140320065406720: error: 0D06407A: asn1 encoding routines: a2d_ASN1_OBJECT: first num too large: crypto / asn1 / a_object.c: 61:
140320065406720: error: 2208206E: X509 V3 routines: r2i_certpol: invalid object identifier: crypto / x509v3 / v3_cpols.c: 135: section:, name: KC1ClassSignTool, value:
140320065406720: error: 22098080: X509 V3 routines: X509V3_EXT_nconf: error in extension: crypto / x509v3 / v3_conf.c: 47: name = certificatePolicies, value = KC1ClassSignTool, KC2ClassSignTool
..

In this regard, CA CAFL63 also refused to create requests and issue certificates on openssl, as it strictly monitored the compliance with the requirements for the CEMS:



At the same time, sometimes these requirements are unnecessary, for example, when using certificates in the educational process, for internal corporate document circulation (signing, document encryption), for accessing https to corporate systems (websites, portals, etc., so-called SSL) certificates).
Based on this, the CAFL63 was refined. Now it became possible not to fill in the extension fields (Tools-> Settings-> System):



The CAFL63 utility allows you to view third-party requests (Certificates-> View a third-party certificate or click the "View external X509" button on the Certificates tab), but with the same drawback:



This refinement allows us today to use CAFL63 TC for educational purposes, for organizing corporate document management, etc. All changes are included in the updated distribution .

That's all I wanted to say in the postscript.