Вхід у VPN за сертифікатом на Mac: особистість, використання ключа чи довіра до шлюзу?
За входом за сертифікатом стоять три рішення: яка особистість обирається, чи може компонент VPN використовувати свій ключ і чи довіряють шлюзу.
Входи у VPN за сертифікатом просять у Mac дещо вужче за пароль: використати саме цей закритий ключ, у цьому контексті виконання, щоб довести шлюзу певну особистість. Коли це не вдається, повідомлення зазвичай описує лише останню річ, що пішла не так, а вона рідко буває причиною. Проходження трьох рішень у тому порядку, у якому їх ухвалює система, зберігає діагностику чесною і не дає сприйняти локальну проблему з дозволами як збій перевірки ланцюжка.
Пройдіть вхід у тому порядку, у якому це робить Mac
Спершу клієнт обирає особистість: сертифікат у парі з придатним закритим ключем, доступний через підтримуване сховище або постачальника облікових даних. Далі компонент VPN запитує криптографічну операцію цим ключем, і локальна модель авторизації відповідає. Лише після успіху обох відбувається віддалене рукостискання, де Mac оцінює шлюз, а шлюз оцінює доказ клієнта.
| Decision | Typical symptom | Where to look |
|---|---|---|
| Identity selection | No valid identity, wrong certificate offered | Profile and which identity the client picked |
| Local key use | Signing or interaction error before any handshake | Execution context and key access rules |
| Remote authentication | Chain, name or client-admission rejection | Gateway identity and what it accepts |
Читайте таблицю згори донизу і зупиніться на першому рядку, який не проходить. Усе нижче збою не доведено, тому «сертифікату не довіряють» — такий частий і такий ненадійний висновок.
Що насправді охоплює локальний дозвіл
У моделі в'язки ключів macOS захищені елементи несуть правила доступу, що залежать від операції, і список довірених програм. Підписування закритим ключем — одна з таких операцій, і правила стосуються виконуваного файлу, який її виконує, а не сертифіката як документа. Довідка Apple з контролю доступу також проводить межу між цією моделлю та в'язкою ключів iCloud і схемами груп доступу, тож порада, написана для однієї, не переноситься на іншу.
Звідси випливають два наслідки. Видимий у списку відкритий сертифікат не доводить, що фоновий компонент VPN узагалі може дістатися до цього ключа. А дозвіл, наданий зовнішній програмі, нічого не каже про окремий помічник чи мережеве розширення, бо це інший код з іншими особистостями.
Визначте фактичну реалізацію та підтримуваний нею механізм спільного використання облікових даних, замість копіювати шлях до виконуваного файлу зі старого клієнта. Спершу підтвердьте, яку особистість система взагалі запропонує:
security find-identity -v -p ssl-clientЯк читати errSecInteractionNotAllowed
Цей статус повідомляє про недозволену взаємодію із Security Server і нічого не каже про ланцюжки сертифікатів. Читайте його разом з операцією, що його спричинила: запит на підпис, виданий із контексту, який не може показати запит, зазнає невдачі саме так, навіть коли і ключ, і сертифікат цілком чинні. Починати треба з операції, яка це записала, а не зі сховища сертифікатів. Будь-яка зміна довірених якорів залишить помилку точно там, де вона була.
Тож розглядайте код як привід перевірити контекст виконання й авторизацію. Якщо вважати його доказом того, що ЦС шлюзу не є довіреним, ви потрапляєте в неправильну половину проблеми, і зроблена там зміна взагалі не вплине на помилку.
Вузьке виправлення, а не широке
Почніть з інструкцій щодо реєстрації або імпорту від власника з'єднання. Зафіксуйте версію клієнта, обсяг профілю, обрану особистість і першу значущу локальну помилку, бо саме ці чотири факти потрібні під час передачі в підтримку і від них залежить подальше порівняння. Керований профіль або особистість з апаратною підтримкою можуть вимагати, щоб адміністратор чи постачальник виправив передачу, і жодна кількість локальних клацань це не замінить.
Там, де продукт очікує підтвердження користувача, з'ясуйте, який компонент його просить, і схваліть лише цей доступ підтримуваним потоком. Там, де компонент не має способу викликати запит у тому контексті, у якому працює, підготовка має йти документованим постачальником шляхом, а не діалогом, витягнутим з іншого вікна термінала.
У старіших порадах дві зміни об'єднують, і обидві надто широкі. Надання кожній програмі доступу до закритого ключа розширює локальне використання ключа далеко за межі вимоги, а встановлення сертифіката в Always Trust змінює оцінювання сертифікатів для всього на машині. Жодна з них не виражає «цю схвалену реалізацію VPN, що використовує цю передбачену особистість».
Перевірте локально, перш ніж читати шлюз
Після виправлення підтвердьте, що локальна операція успішна перш ніж тлумачити будь-яку відповідь з іншого боку. Якщо підписування тепер працює, подальша відмова за іменем, ланцюжком або допуском клієнта — це новий результат, а не повторення, і вона належить іншому рішенню з іншим відповідальним.
Корисна передача називає, яке з трьох рішень не пройшло, і на цьому зупиняється. Вона ніколи не містить закритий ключ і ніколи не скидає сторонні елементи в'язки ключів у надії, що чистий стан допоможе. Заведіть ці дві звички до інциденту, а не під час нього, коли спокуса спробувати все одразу найсильніша. Заявка зі словами «в'язку ключів перезібрано» майже нічого не повідомляє наступному читачеві про первісну несправність.