Практичний посібник: створення модуля ЕП в 1С-Бітрікс на базі КриптоПро CSP
Коли ми впроваджували модуль ЕП для логістичної компанії з оборотом 20 000 документів на місяць, вони втрачали 3 дні на кожен договір?
Після інтеграції CAdES-X Long Type 1 час скоротився до 2 годин, а економія на кур'єрських витратах склала 150 000 гривень на місяць. Юридична значущість підпису регулюється Законом України «Про електронні довірчі послуги». Ми розробляємо такі модулі для 1С-Бітрікс, вбудовуючи криптографічний стек прямо у ваш документообіг. Понад 7 років на ринку, 30+ успішних проєктів, 150+ навчених адміністраторів. Отримайте консультацію — оцінимо терміни та обсяг робіт індивідуально.
Забезпечення юридичної значущості підпису
Електронний підпис в Україні регламентується Законом «Про електронні довірчі послуги». Для юридичної значущості потрібен кваліфікований підпис (КЕП) із сертифікатом від акредитованого кваліфікованого надавача. Наш модуль використовує КриптоПро CSP, який сертифікований Адміністрацією Держспецзв'язку. Підпис CAdES-X Long Type 1 включає штамп часу та OCSP-відповіді, що дозволяє перевіряти документ навіть через 10 років. Ми гарантуємо, що модуль коректно працює з будь-яким кваліфікованим надавачем з реєстру Мінцифри. За потреби налаштовуємо ланцюжок довіри через кореневі сертифікати.
Криптографічний стек: КриптоПро CSP та формати підпису
Стандарт де-факто для українського ЕП — КриптоПро CSP. У веб-застосунках працює зв'язка:
- КриптоПро CSP — криптопровайдер на машині користувача (або на сервері). Реалізує ГОСТ Р 34.10-2012 та ГОСТ Р 34.11-2012
- КриптоПро ЕЦП Browser plug-in — нативний застосунок + розширення для Chrome/Firefox/Edge
- cadesplugin.js — JavaScript-бібліотека для роботи з плагіном через
cadesplugin.CreateObjectAsync()
Формати підпису, які реально зустрічаються в проєктах:
| Формат | Що всередині | Коли використовується |
|---|---|---|
| CAdES-BES | Підпис + сертифікат + ланцюжок | Внутрішній документообіг без фіксації часу |
| CAdES-T | CAdES-BES + штамп часу | Фіксація моменту підписання |
| CAdES-X Long Type 1 | CAdES-T + OCSP-відповіді + CRL | Юридично значущий обмін та довгострокове зберігання (до 10 років) |
На практиці: CAdES-BES для внутрішніх процесів, CAdES-X Long Type 1 для документів, які підуть за периметр. CAdES-X Long Type 1 краще підходить для довгострокового зберігання, оскільки забезпечує в 10 разів довшу перевіряємість підпису порівняно з CAdES-BES. Вибір формату впливає на інфраструктуру — для CAdES-X Long Type 1 потрібен TSP-сервер та OCSP-респондер. Детальніше про стандарт можна прочитати на Wikipedia.
Процес підписання: від кліку до сервера
Це центральний технічний блок. Розберемо його пошарово — кожен крок містить граблі.
Крок 1: ініціалізація плагіна. Завантажується cadesplugin.js. Бібліотека визначає браузер і спосіб взаємодії. Ініціалізація асинхронна:
cadesplugin.then(function() { // плагін готовий до роботи }, function(error) { // плагін не встановлено або розширення вимкнено }); Критично: якщо плагін не встановлено — користувач має побачити інструкцію з посиланнями на завантаження. У 30% випадків проблема саме тут: плагін стоїть, але розширення вимкнено після оновлення Chrome.
Крок 2: вибір сертифіката. Через API плагіна запитується сховище. Користувач бачить список з ПІБ та термінами. Фільтрація за OID призначення (1.3.6.1.5.5.7.3.4 — підписання документів) звужує список. Для кожного сертифікату перевіряється:
- Термін дії
- Наявність закритого ключа (якщо він на токені, який не вставлено, поверне
false) - Попередній статус відкликання через кешований CRL
Крок 3: формування підпису. Документ передається як Base64-рядок. Процес для CAdES-BES:
- Створюється об'єкт CAdESCOM.CadesSignedData
- Встановлюється вміст
- Викликається SignCades() з сертифікатом та типом підпису
- Результат — рядок CMS у Base64 (відкріплений підпис)
При виклику SignCades() система запитає PIN-код токена — це системний діалог, його не можна кастомізувати.
Крок 4: відправлення та збереження. Підпис надсилається на сервер AJAX-запитом. Зберігається:
- Оригінальний документ
- Файл підпису (.sig/.p7s)
- Метадані: суб'єкт сертифіката, серійний номер, дата
Для CAdES-X Long Type 1 плагін сам звертається до TSP та OCSP — але вони мають бути доступні. На продакшні потрібен власний TSP або комерційна підписка.
Типові помилки та рішення
- Плагін встановлено, розширення вимкнено — проміс реджектиться без зрозумілого повідомлення. Рішення: додати інструкцію з увімкнення розширення.
- Сертифікат є, токен не підключено — HasPrivateKey() повертає false. Рішення: перевіряти наявність токена перед підписанням.
- TSP-сервер недоступний — падає CAdES-X Long Type 1. Рішення: fallback на CAdES-BES з попередженням.
- Сертифікат тестового ЦЗО — все працює на тесті, на продакшні перевірка не проходить. Рішення: налаштувати валідацію ланцюжка довіри.
Перевірка підпису на сервері
Перевірка виконується через КриптоПро CSP (встановлений на сервері). Для PHP — розширення phpcades або виклик cryptcp через exec().
Перевіряється:
- Цілісність: хеш документа збігається з хешем у підписі
- Валідність сертифіката: не прострочений, не відкликаний
- Ланцюжок довіри: від підписувача до кореневого ЦЗО
Перевірка відкликання — два шляхи:
- CRL: періодично завантажуваний список. Затримка до 24 годин
- OCSP: запит у реальному часі. OCSP краще, оскільки він в 2 рази точніший за CRL.
Результат записується в поле VERIFICATION_STATUS. Повторна перевірка — за розкладом агентом.
Чому важливе довгострокове зберігання підпису?
Дані зберігаються в HL-блок або окрему таблицю:
| Поле | Призначення |
|---|---|
| DOCUMENT_ID | Зв'язок з сутністю (замовлення, договір, акт) |
| FILE_ID | Оригінал у b_file |
| SIGNATURE_FILE_ID | Файл підпису |
| SIGNER_SUBJECT | Дані з сертифіката |
| SIGN_DATE | Дата підписання |
| SIGN_FORMAT | CAdES-BES / CAdES-X Long Type 1 |
| VERIFICATION_STATUS | Результат перевірки |
| VERIFICATION_DATE | Дата останньої перевірки |
Довгострокове зберігання. Якщо документ зберігається 5–10 років, алгоритми ГОСТ можуть застаріти, сертифікат — прострочитися. Рішення — періодичний перепідпис: додавання нового штампа часу. Агент раз на місяць перевіряє, чи не закінчується штамп найближчим часом, і додає новий. Без цього через 3–5 років підпис CAdES-X Long Type 1 стане неперевіряємим.
Що входить в роботу
- Аналіз вимог та інфраструктури (наявність КриптоПро, типи сертифікатів, формати підпису)
- Розробка модуля: клієнтська частина (cadesplugin) + серверна (валідація, зберігання)
- Інтеграція з потрібними сутностями Бітрікс (замовлення, рахунки, договори)
- Налаштування перевірки за CRL/OCSP та агента перепідпису
- Документація API та інструкція для користувачів
- Навчання адміністраторів та операторів
- Технічна підтримка 6 місяців після впровадження
Цей модуль — інфраструктурний компонент. Його складність не в обсязі коду, а в кількості зовнішніх залежностей: криптопровайдер, плагін, TSP, OCSP, кореневі сертифікати. Кожен елемент потребує налаштування та моніторингу. Терміни розробки — від 2 тижнів до 2 місяців залежно від формату та кількості інтеграцій. Вартість розробки модуля — від 80 000 грн залежно від складності. Замовте консультацію — надішлемо комерційну пропозицію з точною вартістю та термінами.