Сертифікат VPN на Mac: чому вибір ідентичності залишається порожнім
Клієнту потрібен сертифікат разом із закритим ключем, у сховищі, яке він читає. Спершу перевірте ідентичність, а потім чи приймає її шлюз.
Ви встановили сертифікат, він відображається в Keychain Access із зрозумілою назвою, а список вибору ідентичності VPN-клієнта досі порожній. Клієнт шукає не сертифікат. Він шукає ідентичність: сертифікат разом із закритим ключем, який може підтвердити володіння, збережений там, де клієнту дозволено його читати.
Клієнту потрібна саме ідентичність
Платформа безпеки Apple розглядає сертифікат і ідентичність як різні об'єкти. Сертифікат — це відкриті дані. Ідентичність — це той сертифікат разом із його закритим ключем, і лише ідентичність може пройти виклик. Довірений сертифікат CA, натомість, дозволяє клієнту оцінити видавця; він не робить машину власником виданих клієнтських облікових даних.
| Item | What it can do | What it cannot do |
|---|---|---|
| CA or server certificate | Validate the gateway's chain | Authenticate this client |
| Client certificate without key | Nothing for authentication | Prove possession of anything |
| Identity (cert plus key) | Answer the authentication challenge | Guarantee the gateway accepts it |
Тому імпорт файлу .cer ніколи не створює придатну клієнтську ідентичність. Файл містить лише відкриті дані, і жодне перейменування чи довіра не перетворює його на пару ключів.
Три причини, чому список залишається порожнім
Перша — відсутність закритого ключа, тобто процес реєстрації або імпорту його не надав. Друга — сховище, яке клієнт не переглядає: профіль з областю користувача шукає у зв'язці ключів користувача, а елемент, розміщений у системному сховищі, може бути для нього невидимим. Третя — невідповідність призначення або політики, коли сертифікат існує, але недійсний для автентифікації клієнта за правилами розгортання.
security find-identity -v -p ssl-clientЦя команда перелічує ідентичності, які система вважає дійсними для автентифікації клієнта. Якщо їх число нуль, проблема вище VPN-клієнта, і жодне редагування профілю її не виправить. Якщо ідентичність видно тут, але не в клієнті, різниця у сховищі або області клієнта.
Де зберігається закритий ключ і хто може ним користуватися
Коли ви імпортуєте ідентичність через Keychain Access, діалог імпорту пропонує цільову зв'язку ключів. Яка мета правильна, залежить від клієнта й від того, чи має профіль область користувача чи пристрою. Стара відповідь із рекомендацією системної зв'язки ключів не є універсальним правилом, а копіювання елементів між сховищами не є виправленням.
System Roots — це набір довіри. Розміщення сертифіката там змінює те, яким видавцям довіряє система; це не створює закритий ключ і не є сховищем ідентичностей. Переміщення сторонніх сертифікатів заради заповнення списку — це той вид виправлення, після якого на машині залишається назавжди розширений набір довіри.
Доступ до закритого ключа — окремий контроль. Надання кожній програмі дозволу використовувати ключ вирішує проблему вибору одного клієнта й передає ту саму можливість усьому іншому на машині. Надайте його клієнту, якому воно потрібне, і перевірте, чи підтримується ключ апаратно або позначений як неекспортований; якщо так, треба використовувати підтримуваного постачальника, а не експортовану копію.
Як профіль указує на облікові дані
У керованій вбудованій конфігурації IKEv2 профіль посилається на корисне навантаження облікових даних через PayloadCertificateUUID. Важливі зазначена ідентичність і спосіб її надання; редагування відображуваного імені в профілі не виправляє посилання, що вказує на неправильне навантаження або на те, яке так і не передало ключ.
Сторонній постачальник може використовувати зовсім інший механізм вибору, наприклад власне сховище або системний запит. Читайте документацію цього постачальника, а не переносьте припущення вбудованого профілю, і перевіряйте посилання в профілі, який справді встановлено, а не в чернетці консолі керування.
Вибір і прийняття — окремі етапи
Заповнений список означає, що клієнт може знайти ідентичність і скористатися нею. Це нічого не говорить про те, чи прийме її шлюз. Сервер і далі перевіряє видавця, термін дії, статус відкликання та зіставлення цих облікових даних з обліковим записом.
Перевірте обидва етапи явно, у цьому порядку. Переконайтеся, що ідентичність пропонується, підключіться, а потім попросіть власника шлюзу підтвердити, які облікові дані було пред'явлено і яке правило зіставлення їх використало. Якщо клієнт пропонує ідентичність, а сервер її відхиляє, решта роботи на боці сервера. Перевстановлення сертифіката на Mac не змінить цей результат, скільки б разів його не повторювали.