As a Latin American, I’m not really used to the amount of regulations related to cybersecurity that I’ve found in Russia since I started studying here for my master’s degree. Something unique is that while most of the world uses either RSA, ECDSA or, more recently, Ed25519, here in Russia the main algorithm used for digital signatures is GOST R 34.10-2012. And yeah… GOST is not so special, it’s also based on the elliptic-curve discrete logarithm problem; but the point of having it is to have a way to control locally how signatures are managed.

While experimenting with Russia’s main Cryptographic Service Provider, I faced the complexities of Russian regulations, and discovered that a valid signature doesn’t mean the same thing to a mathematician or cryptanalyst as it does to a lawyer from the government.

To see the difference, take the message a signing tool prints when everything goes well: Signature's verified. It sounds final, but it only answers the mathematical question: is this signature the result of this key and this data? It says nothing about whether anyone is obliged to treat the file as signed. In Russia that second question has its own law, Federal Law No. 63-FZ “On Electronic Signature”, and the answer depends on things the math can’t see: who issued the certificate, which tool created the key, and what was actually checked.

A signature can pass the math and still carry very little legal weight. Four things decide that: whether the certificate came from an accredited CA, whether it has the fields the FSB orders require, whether the key was made with a certified tool used the way its documentation says, and whether anyone checked the certificate chain and revocation when verifying. The two examples below miss different ones.

To make this concrete, the article follows two real examples taken from a small lab: a certificate from CryptoPro’s test authority, and one from a certification authority (CA) built with FreeIPA. I read each one against the law as I went, and compare them at the end.

I wrote this for someone who knows what a certificate is, but has never had to ask which of the three Russian signature types they really need (i.e. me). It stays practical. And a warning: I’m a student, not a lawyer, so please don’t use this as a real reference for relevant stuff… this is more like a nice way to understand the whole picture.

What the law distinguishes

So, 63-FZ. The first surprise is that Russia doesn’t have one kind of electronic signature, it has three. Article 5 splits them into simple and enhanced, and then splits the enhanced one in two.

Simple

The simple one is the easy one to picture: anything that proves, with a code or a password, that a specific person did something. The SMS code your bank sends you is a simple signature. Whether it counts for anything depends on Article 9, which says a document is signed this way only if a regulation or an agreement between the parties says so. No agreement, no signature.

Enhanced unqualified

The enhanced unqualified signature is where the cryptography starts. It must be produced by signing the data with a private key (the law’s wording is “cryptographic transformation of the information using a signature key”; with GOST that means a Streebog hash of the data signed with GOST R 34.10-2012), which gives it the properties of any digital signature: it identifies the signer and detects any modification made after signing. It must also be created with signature tools. What the law does not require is a certificate binding the verification key to an identity. One may exist, but nothing demands it.

Enhanced qualified

The enhanced qualified signature is the same thing plus two requirements. The verification key has to appear in a qualified certificate, and both creating and checking the signature must be done with tools that meet the legal requirements. Those two requirements are where the cost and the paperwork come in.

Why the difference matters

The logic behind these decisions is related to the chain of trust built by the legislation and described in Article 6. A qualified signature is treated as equal to handwriting on paper, unless some federal law insists on paper. The other two only get that treatment where a law or an agreement says so. In practice, “qualified” is the one that works without negotiating with the other side first.

Just like math is a way people use to generate trust between two entities, these regulations are made as trust tools for bureaucratic entities.

What qualified costs

And qualified isn’t cheap, because of what sits behind it. The certificate has to be issued by an accredited CA, one that went through the state accreditation process (Articles 15, 16, 16.1 and 17), and it must name both the signature tool and the CA’s own tools. Those tools are classified by two FSB orders from 2011. Order 796 defines six classes, from KS1 to KA1. Each class resists everything the previous one does plus a stronger attacker (see the table below). Order 795 dictates the form of a qualified certificate, including where the class and the tool names have to appear.

Case A: a GOST signature from CryptoPro

The first example is a signature made with CryptoPro CSP 5.0 (build 5.0.13800) in an Ubuntu 22.04 container. I created a key and a certificate with cryptcp, and then signed and verified a small text file. This is the certificate listing:

Subject    : CN=lab-test, O=Lab1
Issuer     : ... CN="Тестовый УЦ ООО ""КРИПТО-ПРО"""
Not valid before : 30/09/2026 13:53:32 UTC
Not valid after  : 30/11/2026 14:03:32 UTC
Signature Algorithm : GOST R 34.11-2012/34.10-2012 256 bit
PublicKey Algorithm : GOST R 34.10-2012 256 bit (512 bits)
Container  : HDIMAGE\\labcert2.000\A2F3
Provider   : Crypto-Pro GOST R 34.10-2012 KC1 CSP

And the verification:

Signer: Lab1, lab-test
Signature algorithm: GOST R 34.10-2012 256 bit (1.2.643.7.1.1.1.1)
Hash algorithm: GOST R 34.11-2012 256 bit (1.2.643.7.1.1.2.2)
Signature's verified.

On the math there is nothing to complain about: a 256-bit GOST R 34.10-2012 signature over a Streebog (GOST R 34.11-2012) hash, exactly as the standard says. At this point I had what the law calls an enhanced signature: made with a key, tied to a signer, and broken by any change to the file.

The rest of the setup was chosen for a lab, and each of those choices maps onto something the law cares about:

Important: the certificate lists OCSP and CRL addresses on the test CA’s own server, so the revocation check could have been run. Leaving it on is a one-flag change.

The tool

CryptoPro CSP 5.0 R3 in class KS1 has FSB certificate SF/114-4920, issued on 1 May 2024 and valid until 1 May 2027, and the provider name printed by the tools says KC1. A later information letter from CryptoPro (No. 15587 of 9 April 2025) quotes an FSB conclusion on an updated version, 5.0 R3+, build 5.0.13003. According to that letter it meets the Order 796 requirements for signature tools of class KC1, covering creation and verification of GOST R 34.10-2012 signatures, the GOST R 34.11-2012 hash and signature key generation, and it may be operated until 1 May 2029. So the product family is certified, and the algorithms I used are the ones the certification covers.

What I ran, though, was 5.0.13800 on Ubuntu 22.04 with a demo license (cpconfig reported 94 days left), while the letter names 5.0.13003 and lists no operating systems for the CSP itself. Whether my build, running in a container on a rented server, is inside the conditions written in the formular (the document that comes with the certified product), I couldn’t establish: I looked for a public copy of the formular and didn’t find one.

So what is this signature, legally?

An enhanced unqualified one, and with a test CA it can’t be anything more: only an accredited CA can issue a qualified certificate. Whoever received it would need an agreement with me to treat it like a handwritten signature.

Case B: a certificate from my own CA

Now the opposite end. FreeIPA 4.13.4 bundles a directory, Kerberos and a certificate authority, and it’s what I used for the domain part of the lab. Before building that CA, the installer tells you what it is about to create:

Subject DN:   CN=Certificate Authority,O=LAB.TEST
Chaining:     self-signed

“Self-signed” means the root vouches for itself and nobody outside stands behind it. That’s fine for a lab domain, and what makes it useful is distribution. When the two client machines joined the domain, the root certificate landed in their trust stores automatically. You can see it with the same HTTPS request from a client. Before enrollment there is no CA file on the client, and curl refuses the connection:

root@cryptosoftware:~/lab01/ipa# docker exec client01 ls /etc/ipa/ca.crt
ls: cannot access '/etc/ipa/ca.crt': No such file or directory
root@cryptosoftware:~/lab01/ipa# docker exec client01 curl -sS -o /dev/null -w '%{http_code}\n' https://ipa.lab.test/ipa/ui
curl: (60) SSL certificate problem: self-signed certificate in certificate chain
More details here: https://curl.se/docs/sslcerts.html

Enrollment is what turns a plain machine into a member of the domain. On each client it’s a single command, ipa-client-install, run with the domain admin’s credentials:

root@cryptosoftware:~/lab01/ipa# docker exec client02 ipa-client-install --unattended --domain=lab.test --realm=LAB.TEST --server=ipa.lab.test --principal=admin --password=******** --mkhomedir --no-ntp --force-join
...
Successfully retrieved CA cert
    Subject:     CN=Certificate Authority,O=LAB.TEST
    Issuer:      CN=Certificate Authority,O=LAB.TEST
    Valid From:  2026-09-30 16:17:56+00:00
    Valid Until: 2046-09-30 16:17:56+00:00

Enrolled in IPA realm LAB.TEST
Created /etc/ipa/default.conf
Configured /etc/sssd/sssd.conf
Systemwide CA database updated.
SSSD enabled
Configured /etc/openldap/ldap.conf
Configured /etc/krb5.conf for IPA realm LAB.TEST
Client configuration complete.
The ipa-client-install command was successful

In that one step the client:

1. Registers itself in the directory: the server now knows the host and gives it a Kerberos identity (host/[email protected]), which is why both clients show up in ipa host-find.
2. Configures login and lookup: SSSD, krb5.conf and ldap.conf are pointed at the IPA server, so domain users and services resolve on the client.
3. Downloads and trusts the root: the CA certificate is saved to /etc/ipa/ca.crt and added to the system-wide trust store (the Systemwide CA database updated line). Every program that uses the system store, curl included, now trusts anything the domain CA signs. That third point is the root certificate distribution policy the assignment asked for: nobody copies a .crt by hand, joining the domain is the distribution.

After enrollment, the same command goes through with no complaint and no special flag (the 301 is just the redirect to /ipa/ui/):

root@cryptosoftware:~/lab01/ipa# docker exec client01 curl -sS -o /dev/null -w '%{http_code}\n' https://ipa.lab.test/ipa/ui
301

I also compared the root’s SHA-256 fingerprint on both clients with the CA’s own, and they matched. From there the CA issued a certificate for client01 (CN=client01.lab.test, O=LAB.TEST, valid for two years), and openssl verify against the root returned OK.

FreeIPA issues from a profile with RSA keys by default, so the certificate carries an RSA 2048-bit public key and is signed with sha256WithRSAEncryption, and the root CA key is RSA 3072. There is no GOST anywhere in that chain. The sources I read show NIST elliptic curves as the alternative and none from the GOST set, although that doesn’t prove GOST is impossible in this stack. The subject is a hostname, as it should be for a server certificate, not a person with a SNILS number or an organization with an OGRN and INN.

Legally, a signature made with those keys would be enhanced unqualified at best. It uses RSA instead of GOST, and I couldn’t find FreeIPA or Dogtag in any list of certified tools (though I never reached the FSB register itself, so that’s not proof). The certificate is a host certificate, not the qualified form, and a private self-signed CA isn’t accredited. Where it goes further than Case A is verification: both clients trust the root, so the whole chain is checked. Like Case A, it would need an agreement between the parties.

That’s what an internal CA is for: TLS, service identity inside a domain and automatic renewal. Producing signatures the law treats as handwritten was never its job.

Side by side

Case A has the GOST cryptography but a test issuer and no chain check. Case B checks the whole chain but uses RSA and a private issuer. Both end up enhanced unqualified, for different reasons.

What would it take to get a qualified signature out of each setup? Case A is close. It needs a certificate from an accredited CA, with the identity fields and tool names Order 795 asks for, a key created inside the certified tool’s documented conditions, and a verification that includes chain and revocation. The cryptography wouldn’t change at all. Case B can’t be tuned into a qualified signature. Accreditation is an organizational and regulatory process, and the signing side would need a certified tool implementing the GOST algorithms. The realistic path is to buy a certificate from an accredited CA and keep the internal one for what it does well.

What I can’t claim

I looked at one certificate from each side, so another CA, profile or tool might behave differently. I read the law partly through secondary sources, and where I couldn’t quote the current text of an article, I say so instead of guessing. Whether this CryptoPro build and my container sit inside the certified conditions stayed open. And a container on a rented server, with the key sitting in files, is a lab setup, not the configuration a certificate is written for.

I didn’t look at court practice or at how a particular counterparty would treat these signatures, and I skipped formats with timestamps and long-term validation, which real use often needs. Everything ran in late September and early October 2026, and laws, certificates and container images keep changing. The FSB certificate SF/114-4920, for instance, runs until 1 May 2027, while the updated 5.0 R3+ is allowed until 1 May 2029 according to the vendor’s letter.

Conclusion

A working GOST signature is not the same as a qualified one. What separates them has nothing to do with the cryptography: an accredited issuer, a certificate in the form Order 795 requires, a certified tool used within its documented conditions, and a verification that checks chain and revocation. A lab built on a test CA or an internal CA can show all of the mechanics, but none of those four things comes with it.

The practical lesson is to decide at design time which kind of signature a process needs. If a document has to carry legal weight without a prior agreement, plan on getting a certificate from an accredited CA, and read the formular of the tool before building on it.

And when you run into a signature in the wild, ask three things. Who issued the certificate? Which certified tool made the key, and under what conditions? What exactly was checked when it was verified?

Important: Signature's verified only answers the third one, and only partly.

Sources

• Federal Law No. 63-FZ “On Electronic Signature” (consultant.ru)
• FSB Order No. 795 of 27.12.2011, form of a qualified certificate
• FSB Order No. 796 of 27.12.2011, requirements for signature tools
• CryptoPro CSP 5.0 R3 KC1, certificate SF/114-4920
• CryptoPro information letter No. 15587 of 09.04.2025
• Streebog (GOST R 34.11-2012)
• Using FreeIPA and certmonger with EC keys
• FreeIPA issue 6319