Капіяванне сертыфіката 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 таксама паведамляе, ці прысутнічае ключ, і гэта вырашае пытанне для гэтага фармату. Ён таксама называе алгарытм і памер ключа і цалкам збаўляецца, калі ключа няма.

Ніколі не ўстаўляйце файл з прыватным ключом у тэму падтрымкі, трэкер задач ці чат, нават калі ён выглядае як сертыфікат, які вы ўжо дзяліліся. Здымкі экрана панэлі ключа заслугоўваюць такой жа асцярогі.

Ключ можа жыць там, адкуль яго не скапіяваць

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

Гэта кантроль, а не перашкода, якую трэба абысці. Аднавіць прыватны ключ з публічнага сертыфіката немагчыма, і любы інструмент, які сцвярджае адваротнае, робіць нешта іншае.

Зарэгіструйце новую асобу замест капіявання

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

Правярайце, аўтэнтыфікуючыся імпартаванай асобай, а не назіраючы за паспяховым імпартам. Кліент, які прыняў публічны сертыфікат у сваё сховішча, нічога не даказаў пра ключ.

Завяршыце, пацвердзіўшы, што сервер прымае новую асобу і што старая ўсё яшчэ паводзіць сябе так, як задумана палітыкай. Гэта завяршае агляд доказам, а не файлам, які выглядае правільным.