We implemented the ES module for a logistics company with a monthly document flow of 20,000 documents. They lost 3 days on each contract. After integrating CAdES-X Long Type 1 with CryptoPro CSP for electronic signatures, the time dropped to 2 hours, and courier cost savings amounted to 150,000 rubles per month. The legal validity of the signature is regulated by Federal Law No. 63-FZ "On Electronic Signatures." We develop such modules for 1C-Bitrix, embedding the cryptographic stack directly into your document flow. With over 10 years of experience — we have completed more than 30 projects. Get a consultation — we will assess timelines and scope individually. Module development cost is calculated individually depending on format and integration complexity.
Ensuring Legal Validity of the Signature
Electronic signatures in Russia are governed by 63-FZ. For legal validity, a qualified signature (QES) with a certificate from an accredited CA is required. Our module uses CryptoPro CSP, which is certified by the FSB of Russia. The CAdES-X Long Type 1 signature includes a timestamp and OCSP responses, allowing verification even after 10 years. We guarantee the module works correctly with any CA from the Ministry of Digital Development's registry. If needed, we configure the trust chain through root certificates.
Cryptographic Stack: CryptoPro CSP and Signature Formats
The de facto standard for Russian ES is CryptoPro CSP. In web applications, the following combination works:
- CryptoPro CSP — cryptographic provider on the user's machine (or server). Implements GOST R 34.10-2012 and GOST R 34.11-2012
- CryptoPro Browser Plugin — native application + extension for Chrome/Firefox/Edge
- cadesplugin.js — JavaScript library for working with the plugin via
cadesplugin.CreateObjectAsync()
Signature formats that actually appear in projects:
| Format | What's Inside | When Used |
|---|---|---|
| CAdES-BES | Signature + certificate + chain | Internal document flow without time stamping |
| CAdES-T | CAdES-BES + timestamp | Fixing the signing moment |
| CAdES-X Long Type 1 | CAdES-T + OCSP responses + CRL | Legally significant exchange and long-term storage (up to 10 years) |
In practice: CAdES-BES for internal processes, CAdES-X Long Type 1 for documents that leave the perimeter. The format choice affects infrastructure — CAdES-X Long Type 1 requires a TSP server and an OCSP responder. CAdES-X Long Type 1 ensures signature verifiability 10 times longer than CAdES-BES (up to 10 years vs. 1-2 years without re-signing). More about the standard can be read on Wikipedia.
Signing Process: From Click to Server
This is the central technical block. Let's break it down layer by layer — each step contains pitfalls.
Step 1: Plugin initialization. cadesplugin.js loads. The library detects the browser and the interaction method. Initialization is asynchronous:
cadesplugin.then(function() {
// plugin ready
}, function(error) {
// plugin not installed or extension disabled
});
Critical: if the plugin is not installed, the user must see instructions with download links. In 30% of cases, the problem is exactly here: the plugin is installed, but the extension is disabled after a Chrome update.
Step 2: Certificate selection. The plugin API queries the store. The user sees a list with names and validity periods. Filtering by OID purpose (1.3.6.1.5.5.7.3.4 — document signing) narrows the list. For each certificate, we check:
- Validity period
- Presence of a private key (if on a token that is not inserted, returns
false) - Preliminary revocation status via cached CRL
Step 3: Signature generation. The document is passed as a Base64 string. Process for CAdES-BES:
- Create a CAdESCOM.CadesSignedData object
- Set the content
- Call SignCades() with the certificate and signature type
- Result: CMS string in Base64 (detached signature)
When SignCades() is called, the system prompts for the token PIN — this is a system dialog and cannot be customized.
Step 4: Sending and saving. The signature is sent to the server via an AJAX request. We save:
- Original document
- Signature file (.sig/.p7s)
- Metadata: certificate subject, serial number, date
For CAdES-X Long Type 1, the plugin itself contacts TSP and OCSP — but they must be accessible. In production, you need your own TSP or a commercial subscription.
Typical errors and solutions
- Plugin installed, extension disabled — promise rejects with no clear message. Solution: add instructions on how to enable the extension.
- Certificate exists, token not connected — HasPrivateKey() returns false. Solution: check token presence before signing.
- TSP server unavailable — CAdES-X Long Type 1 fails. Solution: fallback to CAdES-BES with a warning.
- Test CA certificate — everything works in test, but verification fails in production. Solution: configure trust chain validation.
Server-Side Signature Verification
Verification is performed via CryptoPro CSP (installed on the server). For PHP — the phpcades extension or calling cryptcp via exec().
We verify:
- Integrity: document hash matches the hash in the signature
- Certificate validity: not expired, not revoked
- Trust chain: from signer to root CA
Revocation check — two paths:
- CRL: periodically downloaded list. Up to 24 hours delay
- OCSP: real-time query. OCSP is 2 times more accurate as it gives the current status.
The result is written to the VERIFICATION_STATUS field. Re-verification is done by a scheduled agent.
Why Long-Term Signature Storage Matters
Data is stored in an HL-block or a separate table:
| Field | Purpose |
|---|---|
| DOCUMENT_ID | Link to entity (order, contract, act) |
| FILE_ID | Original in b_file |
| SIGNATURE_FILE_ID | Signature file |
| SIGNER_SUBJECT | Data from certificate |
| SIGN_DATE | Signing date |
| SIGN_FORMAT | CAdES-BES / CAdES-X Long Type 1 |
| VERIFICATION_STATUS | Verification result |
| VERIFICATION_DATE | Last verification date |
Long-term storage. If a document is stored for 5–10 years, GOST algorithms may become obsolete, and the certificate may expire. Solution: periodic re-signing — adding a new timestamp. An agent runs once a month to check if the timestamp is expiring within the next 6 months and adds a new one. Without this, after 3–5 years, a CAdES-X Long Type 1 signature becomes unverifiable.
What's Included in the Work
- Requirements and infrastructure analysis (CryptoPro availability, certificate types, signature formats)
- Module development: client side (cadesplugin) + server side (validation, storage)
- Integration with required Bitrix entities (orders, invoices, contracts)
- Setting up CRL/OCSP checks and the re-signing agent
- API documentation and user instructions
- Administrator and operator training
- 6 months of technical support after deployment
This module is an infrastructural component. Its complexity lies not in the code volume but in the number of external dependencies: cryptographic provider, plugin, TSP, OCSP, root certificates. Each element requires configuration and monitoring. Development timelines — from 2 weeks to 2 months, depending on format and number of integrations. The cost is calculated individually after analysis. Order a consultation — we will send a commercial proposal with an accurate price and timeline.