Коротка відповідь. Файловий ключ ЕЦП/КЕП в Україні трапляється щонайменше в чотирьох форматах: PKCS#12/PFX (.p12/.pfx), JKS (Java KeyStore), PKCS#8 (окремий приватний ключ) та ІІТ Key-6.dat. Різні надавачі видають ключі в різних контейнерах, тому сайт, який приймає «файловий ключ», мусить розуміти всі чотири. У DSTUcrypt це вже зроблено: віджет сам визначає формат контейнера, сам обирає потрібний ключ за призначенням (keyUsage), а користувач просто обирає файл і вводить пароль — усе в браузері, без передавання ключа будь-куди.
Чому файлових форматів кілька — і чому для сайту це біль
Єдиного «українського формату файлового ключа» ніколи не існувало. Інфраструктура КЕП складалася історично: кваліфіковані надавачі будували свої системи на різних програмних стеках, і кожен пакував ключі у той контейнер, який був рідним для його програмного забезпечення. Тому сьогодні різні надавачі видають ключі в різних контейнерах — і всі вони однаково законні та робочі.
Для користувача це непомітно: у нього просто «файл ключа і пароль». А от для сайту, який хоче приймати КЕП, різниця величезна. Кожен формат — це окрема структура даних, окрема схема шифрування паролем, окремі граничні випадки: контейнер без сертифіката, контейнер із кількома ключами, нестандартні розширення файлів. Написати й підтримувати розбір чотирьох контейнерів самотужки — тижні роботи, які не мають жодного стосунку до вашого продукту. А не підтримати хоча б один — означає відмовити частині користувачів прямо на кроці «оберіть ключ».
Чотири формати файлових ключів: що всередині
| Формат | Типовий файл | Що всередині | Особливість |
|---|---|---|---|
| PKCS#12 / PFX | .p12 , .pfx | приватний ключ + сертифікати | міжнародний стандарт контейнера |
| JKS | .jks | сховище ключів і сертифікатів | формат Java KeyStore |
| PKCS#8 | файл ключа | лише приватний ключ | сертифікат часто окремим файлом |
| ІІТ Key-6.dat | Key-6.dat | приватні ключі | поширений в Україні формат ІІТ |
PKCS#12/PFX — міжнародний стандарт криптографічного контейнера. Один захищений паролем файл, у якому лежать і приватний ключ, і сертифікати до нього. Саме PFX-ключ КЕП найзручніший для перенесення між системами, бо його розуміє більшість криптографічного ПЗ у світі.
JKS — Java KeyStore, сховище ключів зі світу Java. Влаштований інакше, ніж PKCS#12, але розв'язує ту саму задачу: кілька ключів і сертифікатів в одному файлі під паролем. Підпис із JKS нічим не відрізняється за результатом — відмінність лише в контейнері.
PKCS#8 — це не контейнер, а «сирий» приватний ключ: стандартизована структура самого ключа, зазвичай зашифрована паролем. Сертифіката всередині може не бути взагалі — тоді його потрібно надати окремим файлом.
Key-6.dat — поширений в Україні формат захищеного сховища ключів розробки ІІТ. Мільйони користувачів знають свій ключ саме як файл із назвою Key-6.dat, тому підтримувати його на українському сайті обов'язково.
Окрема проблема: у контейнері кілька ключів
Контейнер часто містить не один ключ, а два: підписний (для накладання КЕП) і розшифрувальний (для протоколів розподілу ключів — розшифрування адресованих вам даних). Використати треба саме той, що відповідає операції: підписувати розшифрувальним ключем не можна.
Наївне рішення — показати користувачу список ключів із контейнера і попросити обрати. Це найгірший варіант UX: людина бачить два технічні записи з незрозумілими ідентифікаторами і має вгадати правильний. У сертифікаті кожного ключа є поле keyUsage — призначення ключа, — і саме за ним рішення можна ухвалити автоматично. DSTUcrypt робить це за вас: віджет підпису сам знаходить у контейнері підписний ключ, віджет розшифрування — розшифрувальний. Користувач технічних списків не бачить узагалі.
Що це означає для вашого сайту: жодного коду розбору ключів
З боку інтегратора все зводиться до одного виклику. Ви передаєте дані на підпис — а який саме формат ключа обере користувач у віджеті, вашому коду байдуже:
підпис — однаковий код для будь-якого файла ключа
import { embed } from 'https://dstucrypt.io/embed/dstucrypt-embed.mjs';
const signer = await embed('sign', { mount: 'modal' });
// користувач сам обере файл: .p12/.pfx, .jks, PKCS#8 чи Key-6.dat —
// для вашого коду різниці немає
const { signature, accredited } = await signer.sign(fileBytes, {
format: 'CAdES-T',
});
signature.download('document.p7s');
Віджет відкриється модальним вікном, запропонує обрати файл ключа, сам визначить формат контейнера, візьме підписний ключ за keyUsage і поверне готовий підпис. Якщо в контейнері немає сертифіката (типово для PKCS#8) — віджет сам покаже поле для окремого файла сертифіката. За замовчуванням підпис гешується ДСТУ ГОСТ 34.311-95, а сучасну «Купину» (ДСТУ 7564:2014) можна увімкнути однією опцією digest:'kupyna-256' — незалежно від формату файла ключа.
Що дає DSTUcrypt із коробки. Усі формати файлових ключів — PKCS#12/PFX, JKS, PKCS#8, ІІТ Key-6.dat — працюють в одному віджеті без налаштувань. Підписний чи розшифрувальний ключ обирається з контейнера автоматично за keyUsage — користувач не бачить технічних списків. А сам ключ і пароль ніколи не покидають браузер: уся криптографія виконується у WebAssembly всередині нашого iframe і не потрапляє ні на ваш сервер, ні на наш.
Безпека файлових ключів: що радити користувачам
Файловий ключ — найдоступніший носій КЕП, але його безпека повністю залежить від дисципліни власника. Кілька порад, які варто транслювати своїм користувачам:
- Сильний пароль. Контейнер захищений рівно настільки, наскільки складний пароль до нього. Короткий пароль зводить захист файла нанівець.
- Не пересилати ключ поштою чи месенджером. Копії листів і повідомлень залишаються на серверах — файл ключа має зберігатися локально у власника.
- Не завантажувати ключ на сайти. Легітимному сервісу підпису файл ключа на сервері не потрібен. У DSTUcrypt ключ читається й використовується лише в браузері користувача.
- Захищені носії — наступний крок. Для найкритичніших сценаріїв надавачі пропонують апаратні захищені носії, з яких ключ не можна скопіювати. Це вже інша категорія носіїв: DSTUcrypt працює саме з файловими ключами.
Поширені запитання
Які файли ключів КЕП підтримує DSTUcrypt?
PKCS#12/PFX, JKS, PKCS#8 та ІІТ Key-6.dat — усі в одному віджеті. Користувач просто обирає файл ключа і вводить пароль; формат контейнера віджет визначає сам. Апаратні токени (захищені носії) наразі не підтримуються.
У моєму контейнері два ключі — підписний і розшифрувальний. Який буде використано?
Віджет автоматично обирає потрібний ключ за призначенням (keyUsage): для підпису — підписний, для розшифрування — розшифрувальний. Користувач не бачить технічних списків ключів і не може помилитися.
Чи можна пересилати файл ключа поштою або в месенджері?
Ні. Файловий ключ разом із паролем дає повний контроль над вашим підписом, а копії листа чи повідомлення залишаються на серверах. Зберігайте ключ локально, а якщо він міг потрапити до сторонніх — зверніться до свого надавача, щоб скасувати сертифікат і згенерувати новий ключ.
Що робити, якщо в контейнері немає сертифіката?
Деякі контейнери містять лише приватний ключ. У такому разі віджет DSTUcrypt покаже додаткове поле для окремого файла сертифіката — завантажте його поруч із ключем, і підпис пройде як зазвичай.
Читайте також
- Як додати КЕП на сайт за 10 хвилин
- Чому приватний ключ ніколи не повинен покидати браузер
- Кілька підписантів одного документа: мультипідпис
Усі файлові ключі КЕП на вашому сайті — за 10 хвилин
Готові віджети підпису, перевірки та шифрування за ДСТУ. Ключ і пароль не покидають браузер користувача. На кожному новому домені — 7 днів безкоштовно.
Живе демоЯк підключити