Як все починалося
На самому початку періоду самоізоляції мені на пошту надійшов лист:
Перша реакція була природною: це треба або їхати за токенами, або їх повинні привезти, а з понеділка вже всі сидимо вдома, обмеження пересування, та й чим чорт не жартує. Тому відповідь була цілком природною:
І як ми всі знаємо, з понеділка 1 квітня настав період досить жорсткої самоізоляції. Ми теж всі перейшли на віддалення і нам також знадобився VPN. Наш VPN побудований на базі OpenVPN, але доопрацьований з метою підтримки російської криптографії та можливістю роботи з токенами PKCS#11 та контейнерами PKCS#12. Звичайно, тут з'ясувалося, що ми й самі не зовсім були готові до роботи через VPN: у багатьох просто не було сертифікатів, а хтось був прострочений.
Як йшов процес
І ось тут на допомогу прийшла утиліта
Утиліта cryptoarmpkcs дозволила співробітникам, які знаходяться на самоізоляції і мають токени на домашніх комп'ютерах, сформувати запити на сертифікати:
Збережені запити співробітники надсилали електронною поштою мені. Хтось може запитати: - А як же персональні дані, але якщо уважно подивитися, то їх у запиті немає. А сам запит захищений своїм підписом.
Після отримання запиту на сертифікат імпортується в БД УЦ CAFL63:
Після цього запит може бути або відхилений, або затверджений. Для розгляду запиту необхідно його виділити, натиснути праву кнопку миші та вибрати в меню «Прийняти рішення»:
Сама процедура ухвалення рішення абсолютно прозора:
Аналогічно випускається і сертифікат, тільки пункт меню називається «Випустити сертифікат»:
Для перегляду випущеного сертифіката можна скористатися контекстним меню або просто клацнути двічі на відповідному рядку:
Тепер вміст можна переглянути як за допомогою openssl (Вкладка «Текст від OpenSSL»), так і вбудованим переглядачем CAFL63 (вкладка «Текст сертифіката»). В останньому випадку можна скористатися контекстним меню для копіювання сертифіката в текстовому вигляді спочатку в буфер обміну, а потім у файл.
Тут треба зазначити, що змінилося в CAFL63 в порівнянні з першою версією? Щодо перегляду сертифікатів, то ми вже це відзначили. Стало можливим також виділяти групу об'єктів (сертифікати, запити, CRL) та переглядати їх у режимі перегортання (кнопка «Перегляд виділених…»).
Напевно, найголовніше те, що проект викладено у вільному доступі на
Порівняно з попередньою версією програми CAFL63 змінився не тільки сам інтерфейс, але і, як уже було зазначено, додалися нові можливості. Так, наприклад, перероблена сторінка з описом програми, до неї додані прямі посилання на скачування дистрибутивів:
Багато хто запитував і зараз запитує, де взяти ГОСТ-овий openssl. Традиційно я даю
Але зараз до складу дистрибутивів включено тестову версію openssl з російською криптографією.
Тому, коли буде проводитися налаштування УЦ, то в якості openssl, можна буде вказати або /tmp/lirssl_static для linux, або $::env(TEMP)/lirssl_static.exe для Windows:
При цьому необхідно буде створити порожній файл lirssl.cnf та вказати в змінному середовищі оточення LIRSSL_CONF шлях до цього файлу:
Вкладка «Extensions» у налаштуваннях сертифікатів доповнена полем «Authority Info Access», де можна задати точки доступу до кореневого сертифіката УЦ та OCSP-сервера:
Часто доводиться чути, що УЦ не приймають від заявників згенеровані ними запити (PKCS#10) чи, ще гірше, нав'язують формування запитів із генерацією ключової пари на носії через деяке CSP. І відмовляються від генерації запитів на токенах з невилученим ключем (на тому Рутокен ЕЦП-2.0) через інтерфейс PKCS#11. Тому було вирішено додати до функціоналу програми CAFL63 генерацію запитів з використанням криптографічних механізмів токенів PKCS#11. Для підключення механізмів токена був використаний пакет
Бібліотека, необхідна для роботи з токеном, прописується в налаштуваннях для сертифіката:
Але ми відхилилися від основного завдання, пов'язаного із забезпеченням співробітників сертифікатами для роботи в корпоратиній мережі VPN в режимі самоізоляції. Виявилося, що частина співробітників не має токенів. Вирішили забезпечити їх захищеними контейнерами PKCS#12, благо додаток CAFL63 це дозволяє. Спочатку для таких співробітників робимо запити PKCS#10 із зазначенням типу СКЗІ OpenSSL, потім випускаємо сертифікат і упаковуємо його в PKCS12. Для цього на сторінці «Сертифікати» вибираємо потрібний сертифікат, натискаємо праву кнопку миші та вибираємо пункт «Експорт до PKCS#12»:
Для того, щоб переконатися, що з контейнером все гаразд, скористаємося утилітою cryptoarmpkcs:
Тепер можна надсилати співробітникам випущені сертифікати. Комусь надсилаються просто файли із сертифікатами (це власники токенів, ті, хто надсилав запити), або контейнери PKCS#12. У другому випадку кожному співробітнику телефоном повідомляється пароль до контейнера. Цим співробітникам достатньо виправити конфігураційний файл VPN, правильно прописавши шлях до контейнера.
Щодо власників токена, то їм необхідно було ще імпортувати сертифікат на свій токен. Для цього вони використовували ту саму утиліту cryptoarmpkcs:
Тепер мінімальні редагування конфіга VPN (можна змінити мітка сертифіката на токені) і все, корпоративна мережа VPN в робочому стані.
Щасливий кінець
І тут до мене дійшло, а навіщо людям привозити токени мені чи мені посилати гінця по них. І я надсилаю листа наступного змісту:
Відповідь надходить наступного дня:
Я відразу надсилаю посилання на утиліту cryptoarmpkcs:
Перед створенням запитів на сертифікати я рекомендував їм почистити токени:
Потім електронною поштою були надіслані запити на сертифікати у форматі PKCS#10 і я випустив сертифікати, які надіслав на адресу:
І тут настав приємний момент:
А був ще й такий лист:
І ось після цього народилася ця стаття.
Дистрибутиви програми CAFL63 для платформ Linux та MS Windows можна знайти
тут
Дистрибутиви утиліти cryptoarmpkcs, включаючи платформу Android, знаходяться
тут
Джерело: habr.com