Копіювання сертифіката VPN не копіює ключ

Огляд починається зі списку сертифікатів клієнта, де запис показує ім'я, видавця й дату завершення строку дії і більше нічого. Експортуйте його, імпортуйте на другому пристрої, і з'єднання буде відхилено, бо клієнт не може довести володіння закритим ключем. Файл скопійовано повністю; помилка в тому, щоб очікувати, що сертифікат несе власний ключ. Прочитайте діалог експорту, перш ніж вибирати формат, а потім дослідіть файл, який ви справді отримали.

Два клацання, два зовсім різні артефакти.

Читайте діалог експорту, а не розширення файлу

Експорт сертифіката DER або PEM містить відкритий ключ і підписані твердження про ідентичність, тобто те, що потрібно серверу, щоб довіряти вам, і те, що потрібно клієнту, щоб перевіряти сервер. Пакет PKCS#12 — це контейнер, який може зберігати сертифікат, його ланцюжок і відповідний закритий ключ, захищений паролем, хоча його можна створити й без ключа.

PEM — це лише текстове кодування, а не обіцянка щодо вмісту. Те саме розширення може описувати один сертифікат або файл із кількома позначеними блоками, і що саме — вирішують параметри експорту.

Тож корисне питання — не яке розширення ви отримали, а які блоки містить файл. Пакет, експортований без ключа, залишається пакетом. Перевіряйте вміст, а не популярність формату.

Дослідіть, що ви справді отримали

Шукайте позначки, перш ніж щось імпортувати, а потім прочитайте поля сертифіката, щоб підтвердити, яку ідентичність ви тримаєте. Виконуйте перевірки на тому файлі, який справді буде імпортовано. Повторюйте їх після кожного повторного експорту, бо параметри можуть відрізнятися.

grep -E 'BEGIN (CERTIFICATE|PRIVATE KEY|ENCRYPTED PRIVATE KEY)' bundle.pem
openssl x509 -in client.crt -noout -subject -issuer -dates
openssl pkey -in client.key -noout -text | head -5
openssl pkcs12 -info -in client.p12 -noout

Експорт лише з блоком сертифіката — це публічний об'єкт, і він не може автентифікуватися. Блок ключа без сертифіката залишає вас без ланцюжка, якого очікує сервер. Вивід відомостей PKCS#12 також повідомляє, чи є ключ, і це вирішує питання для цього формату. Він називає й алгоритм, і розмір ключа, і цілком завершується помилкою, коли ключа немає.

Ніколи не вставляйте файл із закритим ключем у тему підтримки, трекер задач чи чат, навіть коли він виглядає як сертифікат, яким ви вже ділилися. Знімки екрана панелі ключів заслуговують на таку саму обережність.

Ключ може бути там, звідки його не можна скопіювати

На керованих пристроях закритий ключ може зберігатися у зв'язці ключів операційної системи, в апаратному токені або в захищеному анклаві, а політика позначає його як неекспортований. Тоді менеджер сертифікатів показує публічний об'єкт, поки секрет залишається на місці, і жодна команда експорту не створить переносну копію. Реєстрація через керування мобільними пристроями часто працює саме так за задумом.

Це контроль, а не перешкода, яку треба обходити. Відновити закритий ключ із відкритого сертифіката неможливо, і будь-який інструмент, який це стверджує, робить щось інше.

Зареєструйте нову ідентичність замість копіювання

Підтримуваний шлях зазвичай такий: зареєструвати окрему ідентичність для нового пристрою й відкликати стару, коли її виводять з експлуатації, щоб кожен пристрій можна було відкликати незалежно. Там, де експорт із ключем справді схвалено, ставтеся до отриманого файлу та його пароля як до облікових даних: зашифровані під час зберігання, передані довіреним каналом і видалені після завершення реєстрації.

Перевіряйте, автентифікуючись імпортованою ідентичністю, а не спостерігаючи за успіхом імпорту. Клієнт, який прийняв публічний сертифікат до свого сховища, нічого не довів щодо ключа.

Завершіть підтвердженням, що сервер приймає нову ідентичність і що стара поводиться так, як задумано політикою. Так огляд закривається доказами, а не файлом, який виглядає правильним.