Это оказалось непросто выяснить, но все-таки задача выполнима.

Я использовал openssl 1.1.1q из Рутокен SDK. Добавил в openssl.cnf секции, адресуемые как oid_section и stbl_section:

openssl_conf = openssl_def

[ openssl_def ]
# engines = engine_section # uncomment if you use rtengine
oid_section = oids
stbl_section = stbl

[ oids ]
OGRNIP=1.2.643.100.5

[ stbl ]
OGRNIP=min:15, max:15, mask:NUMERICSTRING, flags:nomask

После этого в запрос на сертификат OGRNIP попадает с типом NumericString.

При использовании openssl 3.0, полагаю, достаточно будет только секции stbl.

   32:d=5  hl=2 l=   5 prim: OBJECT            :OGRN
   39:d=5  hl=2 l=   4 prim: NUMERICSTRING     :1234
   45:d=3  hl=2 l=  15 cons: SET               
   47:d=4  hl=2 l=  13 cons: SEQUENCE          
   49:d=5  hl=2 l=   5 prim: OBJECT            :OGRNIP
   56:d=5  hl=2 l=   4 prim: UTF8STRING        :1234

Сходу как-то не удалось понять, можно ли как-то заставить openssl изменить тип, но кажется, что нельзя. Как-то можно избавиться от этого различия?

Поведение такое и у версий 1.1.1f и 3.0.14, разве что у первой надо ещё OID вручную добавлять.

Смущает только одно: что на windows с тем же набором опций запросы на сертификат создаются.

Как исправить вашу проблему: добавить опцию -new.

Без этой опции (и без опции -x509 или без опции -in <filename>) утилита openssl req ожидает, что на вход через stdin будет передан существующий запрос на сертификат (см. https://github.com/openssl/openssl/blob … q.c#L688).

OPENSSL_CONF=openssl.cnf openssl req -utf8 -engine rtengine -keyform engine -key 'pkcs11:id=token_id' -out cert.req -subj "/C=RU/ST=<регион>/L=<населенный_пункт>/O=<организация>/OU=<отдел>/CN=<ФИО>/emailAddress=<email>"

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

В windows с тем же токеном и софтом Рутокен запросы на сертификаты создаются.

Версия openssl: 1.1.1f
rtengine: 1.6.0

Здравствуйте OlegShtch, возможно вам будет полезна статья по сценарию работы с engine https://dev.rutoken.ru/pages/viewpage.a … d=43450394
Там есть команда проверки подписи в формате CMS:

openssl cms -verify -binary -in signed_cms -inform PEM -out verified_data -CAfile demoCA/cacert.pem -content data_to_sign

Возможно так получится.

Да, так тоже работает.

Теперь пробую наоборот подписать файл.

Использую следующий конфигурационный файл:

openssl_conf = openssl_init
 
[openssl_init]
engines = engine_section
 
[engine_section]
rtengine = rtengine_section

[rtengine_section]
engine_id = rtengine
dynamic_path = /usr/lib/x86_64-linux-gnu/engines-3/librtengine.so
enable_rand = yes
rand_token = pkcs11:manufacturer=Aktiv%20Co.;model=Rutoken%20ECP;serial=411d5727
pkcs11_path = /usr/lib/librtpkcs11ecp.so
default_algorithms = ALL

OPENSSL_CONF=openssl.cnf openssl cms -sign -binary -nosmimecap -in Test-doc.txt -out Test-doc.txt.sig -outform PEM -keyform engine -inkey "pkcs11:model=Rutoken%20ECP;manufacturer=Aktiv%20Co.;serial=411d5727;token=Rutoken%20ECP%20%3Cno%20label%3E;id=%53...%36;object=S...6;type=private" -engine rtengine -signer my.crl
Engine "rtengine" set.
Could not read signing key from org.openssl.engine:rtengine:pkcs11:model=Rutoken%20ECP;manufacturer=Aktiv%20Co.;serial=411d5727;token=Rutoken%20ECP%20%3Cno%20label%3E;id=%53...%36;object=S...6;type=private
4087DBC37A7F0000:error:40800088:lib(129):ERR_RTENG_error:no pkcs11 library loaded:engine/standalone/standalone.c:469:
4087DBC37A7F0000:error:13000080:engine routines:ENGINE_load_private_key:failed loading private key:../crypto/engine/eng_pkey.c:79:

Судя по strace /usr/lib/x86_64-linux-gnu/engines-3/librtengine.so подгружается, к /usr/lib/librtpkcs11ecp.so обращений не идёт, а ключ подписи пытается прочитаться с диска.

При этом при проверке движка через команду engine всё корректно проверяется. Если ошибиться в пути к библиотеке или токену будет показана ошибка:

OPENSSL_CONF=openssl.cnf openssl engine -vvvv -tt -c -pre pkcs11_path:/usr/lib/librtpkcs11ecp.so -pre enable_rand:yes -pre "rand_token:pkcs11:manufacturer=Aktiv%20Co.;model=Rutoken%20ECP;serial=411d5727" rtengine
(rtengine) Rutoken engine
[Success]: pkcs11_path:/usr/lib/librtpkcs11ecp.so
[Success]: enable_rand:yes
[Success]: rand_token:pkcs11:manufacturer=Aktiv%20Co.;model=Rutoken%20ECP;serial=411d5727
 [RAND, gost89, gost89-cnt, gost89-cnt-12, gost89-cbc, gost89-ecb, kuznyechik-ecb, kuznyechik-cbc, kuznyechik-ofb, kuznyechik-cfb, kuznyechik-ctr, kuznyechik-ctr-acpkm, kuznyechik-ctr-acpkm-omac, magma-ecb, magma-cbc, magma-ofb, magma-cfb, magma-ctr, magma-ctr-acpkm, magma-ctr-acpkm-omac, md_gost94, md_gost12_256, md_gost12_512, gost-mac, gost-mac-12, kuznyechik-mac, magma-mac, gost2001, gost-mac, gost2012_256, gost2012_512, gost-mac-12, kuznyechik-mac, magma-mac]
     [ available ]
     enable_rand: Enable rand method
          (input flags): STRING
     pkcs11_path: Path to PKCS#11 library
          (input flags): STRING
     rand_token: Rand token URI
          (input flags): STRING

P.S. Решилось перемещением строки pkcs11_path сразу после dynamic_path, без этого она не вызывалась, а также удалением ;type=private из URL.

openssl cms -verify -binary -in signed_cms -inform PEM -out verified_data -CAfile demoCA/cacert.pem -content data_to_sign

Возможно так получится.

Теперь пытаюсь проверить локально с помощью openssl на Debian testing:

Преобразовываем подпись из base64 в DER:

openssl base64 -d -a -nopad -in signature_140854_10112022.sig -out signature_140854_10112022.sig.der

Проверяем, что подпись в формате PKCS#7:

openssl pkcs7 -inform der -in signature_140854_10112022.sig.der -print

Извлекаем открытый ключ из сертификата:

openssl x509 -engine rtengine -in Test.crt -pubkey -out Test.pem

Проверяем подпись, возвращается "Verification failure":

openssl dgst -engine rtengine -verify Test.pem -signature signature_140854_10112022.sig.der Test-doc.txt

С -engine gost всё также не работает.

Версии пакетов

openssl: 3.0.7-1
libengine-gost-openssl: 3.0.1-2+b1
librtengine3: 3.1.1
librtpkcs11ecp: 2.6.1.0
rutokenplugin: 4.7.0-1

P.S. Разобрался, нашёл в недрах интернета пример:

openssl smime -engine gost -verify -CAfile caGost256.crt -no_check_time -in signature_140854_10112022.sig.der -inform der -content Test-doc.txt

openssl x509 -req -in democa/newcerts/client01.csr -CA democa/certs/cacert.pem -CAkey democa/private/cakey.pem -CAcreateserial -out democa/certs/client01_gost.pem -days 365

С ней файл успешно формируется.

Ещё раз спасибо большое за помощь.

Конфиг openssl

openssl req -new -x509 -key demoCA/private/cakey.pem -out demoCA/certs/cacert.pem -extensions v3_ca -days +3650 -outform PEM

v3_ca в конфиге:

[ v3_ca ]

subjectKeyIdentifier=hash

authorityKeyIdentifier=keyid:always,issuer

#basicConstraints = critical,CA:true
basicConstraints = CA:true

C:\openssl-1.1.1q>openssl x509 -in demoCA/certs/cacert.pem -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            0a:1d:07:19:ae:31:0c:3e:45:6f:c9:4d:e9:61:5d:69:f1:4b:39:11
        Signature Algorithm: GOST R 34.10-2012 with GOST R 34.11-2012 (256 bit)
        Issuer: C = RU, ST = MSK, O = CA, OU = CA, CN = CA
        Validity
            Not Before: Aug 25 09:25:05 2022 GMT
            Not After : Aug 22 09:25:05 2032 GMT
        Subject: C = RU, ST = MSK, O = CA, OU = CA, CN = CA
        Subject Public Key Info:
            Public Key Algorithm: GOST R 34.10-2012 with 256 bit modulus
                Public key:
                   X:1B4DD59E1EC4E2E20CB38A892AA26705E9EB2B4037063AC8368C53A3F33D97D7
                   Y:79FD4EE602E09D89EC7A9D27FE4C253C4194882B0548A830C35D22D7D3AA896B
                Parameter set: GOST R 34.10-2012 (256 bit) ParamSet A
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                66:50:2D:6A:E2:AD:9D:25:7A:A8:63:09:D9:41:D0:C5:61:16:8F:9D
            X509v3 Authority Key Identifier:
                keyid:66:50:2D:6A:E2:AD:9D:25:7A:A8:63:09:D9:41:D0:C5:61:16:8F:9D

            X509v3 Basic Constraints:
                CA:TRUE
    Signature Algorithm: GOST R 34.10-2012 with GOST R 34.11-2012 (256 bit)
         2d:00:16:ef:7b:33:d8:f3:c8:d4:9e:c6:84:67:95:51:7c:fd:
         26:19:55:47:9a:d6:f6:c9:1e:a3:18:b2:ef:c1:10:a7:e2:1d:
         6c:4f:7a:33:e9:f1:f5:37:4e:91:95:f6:6f:52:07:55:30:4f:
         ad:23:1b:ee:4c:da:a9:42:94:53

[ ca ]
default_ca    = CA_default        # The default ca section

####################################################################
[ CA_default ]

dir        = ./demoCA
certs        = $dir/certs
crl_dir        = $dir.crl]        # Where the issued crl are kept
database    = $dir/index.txt    # database index file.
#unique_subject    = no            # Set to 'no' to allow creation of  several certs with same subject.
new_certs_dir    = $dir/newcerts

certificate    = $dir/certs/cacert.pem

serial        = $dir/serial.
crlnumber    = $dir]crlnumber.    # the current crl number  must be commented out to leave a V1 CRL
crl        = $dir]crl.pem         # The current CRL

private_key    = $dir/private/cakey.pem

x509_extensions    = usr_cert        # The extensions to add to the cert

# Comment out the following two lines for the "traditional"
# (and highly broken) format.
name_opt     = ca_default        # Subject Name options
cert_opt     = ca_default        # Certificate field options

# Extension copying option: use with caution.
# copy_extensions = copy

# Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs
# so this is commented out by default to leave a V1 CRL.
# crlnumber must also be commented out to leave a V1 CRL.
# crl_extensions    = crl_ext

default_days    = 365            # how long to certify for
default_crl_days= 30            # how long before next CRL
default_md    = default        # use public key default MD
preserve    = no            # keep passed DN ordering

# A few difference way of specifying how similar the request should look
# For type CA, the listed attributes must be the same, and the optional
# and supplied fields are just that :-)
policy        = policy_match