Коротка відповідь. ЕЦП («електронний цифровий підпис») — застарілий термін із попереднього законодавства, який досі живе в побуті. Сьогодні закон України про електронну ідентифікацію та електронні довірчі послуги вживає три поняття: ЕП (електронний підпис — найзагальніше), УЕП (удосконалений електронний підпис — криптографічний, але без кваліфікованого статусу) і КЕП (кваліфікований електронний підпис). Юридичну силу власноручного підпису «з коробки» має лише КЕП; УЕП працює за домовленістю сторін. Технічно КЕП від УЕП відрізняє кваліфікований сертифікат від акредитованого надавача — і саме це показує поле accredited у результаті перевірки DSTUcrypt.
Словник: ЕЦП, ЕП, УЕП, КЕП
Почнімо з термінів, бо саме тут народжується більшість плутанини.
- ЕЦП (електронний цифровий підпис) — термін попереднього закону. Офіційно він уже не вживається, але в побуті «ЕЦП» досі кажуть — і майже завжди мають на увазі те, що чинний закон називає КЕП. Якщо контрагент пише «підпишіть ЕЦП», у 99 % випадків ідеться про КЕП.
- ЕП (електронний підпис) — найширше поняття: будь-які електронні дані, що додаються до документа й дозволяють ідентифікувати підписанта. Формально під це визначення підпадає навіть набране ім'я під листом чи «галочка» у формі — жодної криптографії тут може не бути.
- УЕП (удосконалений електронний підпис) — уже «справжній» криптографічний підпис: створюється особистим ключем, однозначно пов'язаний із підписантом і дозволяє виявити будь-яку зміну документа після підписання. Але сертифікат підписанта не обов'язково кваліфікований.
- КЕП (кваліфікований електронний підпис) — той самий криптографічний підпис, але з двома додатковими умовами: сертифікат — кваліфікований, виданий кваліфікованим (акредитованим) надавачем електронних довірчих послуг, а ключ зберігається у захищеному засобі. Саме КЕП — «золотий стандарт» для документів із повною юридичною силою.
Тобто ієрархія проста: ЕП ⊃ УЕП ⊃ КЕП. Кожен КЕП — це УЕП, і кожен УЕП — це ЕП, але не навпаки.
Юридична різниця: що прирівняне до власноручного підпису
Головна практична відмінність — у правових наслідках.
КЕП прирівняний до власноручного підпису законом. Документ із КЕП має таку саму юридичну силу, як паперовий із «живим» підписом, — без жодних додаткових угод. Тому саме КЕП приймають державні реєстри, податкова звітність, судові та банківські системи.
УЕП діє за домовленістю сторін. Закон дозволяє використовувати удосконалений підпис у відносинах, де сторони про це домовилися: наприклад, компанія і її клієнти погоджують у договорі чи публічній оферті, що документи, підписані УЕП, визнаються обома сторонами. Усередині такої домовленості УЕП цілком робочий інструмент — але за її межами (скажімо, у відносинах із державним органом, який вимагає КЕП) його сила не гарантована.
Простий ЕП — найслабший рівень: його доказова цінність залежить від обставин і теж тримається на домовленостях, але без криптографії довести цілісність документа й особу підписанта значно складніше.
Технічна різниця: сертифікат, надавач, засіб
Криптографічно УЕП і КЕП можуть бути влаштовані однаково: в українській практиці це підпис на еліптичних кривих за ДСТУ 4145-2002 у парі з геш-функцією — ДСТУ ГОСТ 34.311-95 або сучасною «Купиною» (ДСТУ 7564:2014). Сам файл підпису (CAdES, PAdES, XAdES чи ASiC) на вигляд не відрізняється. Різниця — в атрибутах довіри навколо ключа:
- Хто видав сертифікат. Для КЕП сертифікат має бути кваліфікованим — виданим акредитованим надавачем електронних довірчих послуг, ланцюжок якого простежується до офіційного кореня центрального засвідчувального органу. Сертифікат від «самопального» чи неакредитованого центру дає щонайбільше УЕП.
- Де живе ключ. Для КЕП особистий ключ має зберігатися у засобі, що відповідає вимогам до засобів кваліфікованого підпису.
- Що написано в сертифікаті. Кваліфікований сертифікат містить обов'язкові позначки й дані підписанта — ПІБ, РНОКПП або ЄДРПОУ, — які й дозволяють юридично однозначно ідентифікувати особу.
Висновок для розробника: «дійсний підпис» і «КЕП» — не синоніми. Підпис може бути криптографічно бездоганним (математика зійшлася, документ не змінювався), але якщо сертифікат не від акредитованого надавача — це УЕП, і приймати його як КЕП не можна.
Як програмно відрізнити КЕП від УЕП: поле accredited
Саме для цього в результатах перевірки DSTUcrypt є окреме поле accredited. Віджет verify виконує повну валідацію — криптографію, ланцюжок сертифікатів, OCSP/CRL, мітки часу — і для кожного підписанта повертає, зокрема, вердикт valid і статус акредитації надавача:
перевірка підпису: дійсний? а це точно КЕП?
import { embed } from 'https://dstucrypt.io/embed/dstucrypt-embed.mjs';
const verifier = await embed('verify', { mount: 'modal' });
const report = await verifier.verify(signatureBytes, null); // null — підпис вкладений (attached)
for (const s of report.signers) {
console.log(s.signerName, s.signerCode); // ПІБ і РНОКПП/ЄДРПОУ з сертифіката
if (!s.valid) continue; // підпис недійсний — далі нема про що говорити
if (s.accredited === true) { /* КЕП: надавач акредитований */ }
if (s.accredited === false) { /* дійсний підпис, але НЕ КЕП (УЕП) */ }
if (s.accredited === null) { /* акредитацію не перевірено */ }
}
Розберімо ключові поля кожного елемента signers:
valid— чи дійсний підпис криптографічно: математика підпису зійшлася й документ не змінювався після підписання.accredited— чи виданий сертифікат підписанта акредитованим надавачем:true— це КЕП;false— підпис дійсний, але не КЕП;null— дані довіри недоступні, акредитацію не перевірено.signerNameіsignerCode— ПІБ (або назва організації) та РНОКПП/ЄДРПОУ з сертифіката: саме те, що потрібно, щоб зіставити підписанта з вашим користувачем чи контрагентом.
Те саме поле accredited повертає й метод sign() — одразу після накладання підпису, — і серверний ендпойнт POST /api/verify, який на кожного підписанта віддає accredited та qualified. Важливо: якщо на підставі перевірки ваш бекенд ухвалює рішення (прийняти документ, зарахувати платіж), довіряйте лише серверній перевірці — браузерний вердикт контролює користувач.
Чому це зручно саме в DSTUcrypt. Уся криптографія виконується у браузері користувача: ключ і пароль не покидають його ні за яких умов. Ядро — перевірена C/C++-бібліотека, скомпільована у WebAssembly, з підтримкою 16 форматів підпису (CAdES, PAdES, XAdES, ASiC-S/E усіх рівнів) і повного стека нацстандартів: «Купина», «Калина», ДСТУ 4145. А статус акредитації надавача — просто поле в результаті, без окремих запитів до реєстрів.
Порівняльна таблиця: ЕП, УЕП, КЕП
| ЕП (простий) | УЕП | КЕП | |
|---|---|---|---|
| Що це | будь-які електронні дані, що ідентифікують підписанта | криптографічний підпис особистим ключем | криптографічний підпис із кваліфікованим сертифікатом |
| Криптографія | не обов'язкова | так (в Україні — ДСТУ 4145) | так (в Україні — ДСТУ 4145) |
| Сертифікат | немає | є, але не обов'язково кваліфікований | кваліфікований, від акредитованого надавача |
| Виявлення змін у документі | ні | так | так |
| Юридична сила | обмежена, залежить від обставин | за домовленістю сторін | прирівняний до власноручного підпису законом |
| Поле accredited у перевірці DSTUcrypt | — (нема чого перевіряти) | false (підпис дійсний, але не КЕП) | true |
Що обрати бізнесу для яких документів
Практичне правило: що вищі юридичні ризики документа — то вищий рівень підпису.
- КЕП — для всього, що має беззаперечно «тримати удар»: договори з контрагентами, кадрові документи, акти й рахунки, звітність, будь-яка взаємодія з державними системами. Це найбезпечніший вибір за замовчуванням: не треба доводити наявність домовленості про електронну форму.
- УЕП — для замкнених екосистем, де ви самі контролюєте обидві сторони й закріпили правила у договорі чи оферті: внутрішній документообіг, погодження у корпоративних системах, деякі B2C-сценарії. Дешевше й гнучкіше, але поза вашою екосистемою сила підпису не гарантована.
- Простий ЕП — лише для низькоризикових підтверджень (згоди, ознайомлення), де вам достатньо слабкої доказовості.
Якщо ваш сайт приймає підписані документи від зовнішніх користувачів, найпростіша робоча політика така: перевіряти кожен підпис і приймати лише ті, де valid === true і accredited === true. Як побудувати таку перевірку повністю — від криптографії до OCSP і міток часу — ми детально розібрали у статті про перевірку електронного підпису на сайті.
Поширені запитання
Чи можна досі казати «ЕЦП», чи це помилка?
«ЕЦП» — термін із попереднього законодавства, який офіційно вже не вживається. Чинний закон України про електронну ідентифікацію та електронні довірчі послуги оперує поняттями «електронний підпис», «удосконалений електронний підпис» (УЕП) і «кваліфікований електронний підпис» (КЕП). У побуті «ЕЦП» кажуть досі й найчастіше мають на увазі саме КЕП, але в договорах і регламентах краще вживати сучасні терміни.
Чи має УЕП юридичну силу?
Так, але не автоматично. УЕП застосовується за домовленістю сторін: якщо ви письмово погодили електронну взаємодію з удосконаленим підписом, такі документи мають силу у ваших відносинах. На відміну від нього, КЕП прирівняний до власноручного підпису самим законом і працює без окремих домовленостей — зокрема у відносинах із державою.
Як програмно перевірити, що підпис — саме КЕП?
За полем accredited у результаті перевірки DSTUcrypt: true — сертифікат підписанта виданий акредитованим надавачем, тобто це КЕП; false — підпис криптографічно дійсний, але не КЕП; null — акредитацію не перевіряли. Поле є і в результаті sign(), і в кожного signer у verify(). Коли рішення ухвалює бекенд — використовуйте авторитетний серверний POST /api/verify, який повертає ті самі accredited і qualified.
Чи можна накласти КЕП файловим ключем просто у браузері?
Так. Кваліфіковані надавачі видають зокрема файлові ключі, а DSTUcrypt відкриває контейнери PKCS#12/PFX, JKS, PKCS#8 та Key-6.dat прямо у браузері (WebAssembly): ключ і пароль не потрапляють ні на сайт-хост, ні на сервери сервісу. Апаратні токени не підтримуються.
Читайте також
- Перевірка електронного підпису на сайті: криптографія, ланцюжок, OCSP і мітки часу
- Вхід на сайт за КЕП: авторизація користувачів електронним підписом
- Формати електронного підпису: CAdES, PAdES, XAdES, ASiC — який обрати
КЕП на вашому сайті — за 10 хвилин
Готові віджети підпису, перевірки та шифрування за ДСТУ. Ключ і пароль не покидають браузер користувача. На кожному новому домені — 7 днів безкоштовно.
Живе демоЯк підключити