Вы ўсталявалі сертыфікат, ён з’яўляецца ў Keychain Access са зручнай назвай, а спіс выбару ідэнтычнасці ў кліенце VPN усё яшчэ пусты. Кліент не шукае сертыфікат. Ён шукае ідэнтычнасць: сертыфікат разам з прыватным ключом, які можа даказаць валоданне, захаваны там, дзе кліенту дазволена чытаць.

Што кліент запытвае — гэта ідэнтычнасць

Сістэма бяспекі Apple разглядае сертыфікат і ідэнтычнасць як розныя аб’екты. Сертыфікат — гэта публічныя даныя. Ідэнтычнасць — гэта той сертыфікат плюс яго прыватны ключ, і толькі ідэнтычнасць можа завяршыць выпрабаванне. Давераны сертыфікат CA тым часам дазваляе кліенту ацаніць выдаўца; ён не робіць машыну ўладальнікам выдадзенага кліенцкага пасведчання.

ItemWhat it can doWhat it cannot do
CA or server certificateValidate the gateway's chainAuthenticate this client
Client certificate without keyNothing for authenticationProve possession of anything
Identity (cert plus key)Answer the authentication challengeGuarantee the gateway accepts it

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

Тры прычыны, чаму спіс застаецца пустым

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

security find-identity -v -p ssl-client

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

Дзе жыве прыватны ключ і хто можа ім карыстацца

Калі вы імпортуеце ідэнтычнасць праз Keychain Access, дыялог імпарту прапануе сховішча прызначэння. Якое прызначэнне правільнае, залежыць ад кліента і ад таго, ці профіль прывязаны да карыстальніка або да прылады. Стары адказ, які рэкамендуе сістэмнае сховішча, не з’яўляецца ўніверсальным правілам, і капіраванне элементаў паміж сховішчамі не з’яўляецца рамонтам.

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

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

Як профіль паказвае на пасведчанне

У кіраванай убудаванай канфігурацыі IKEv2 профіль спасылаецца на сваю нагрузку пасведчання праз PayloadCertificateUUID. Важна ідэнтычнасць, на якую ёсць спасылка, і спосаб яе прадастаўлення; рэдагаванне адлюстраванай назвы ў профілі не выпраўляе спасылку, якая паказвае на няправільную нагрузку або на тую, што ніколі не перадала ключ.

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

Выбар і прыняцце — асобныя этапы

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

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

Падобныя артыкулы