Влизане във 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
Този статус съобщава за забранено взаимодействие със Сървъра за сигурност и не казва нищо за веригите от сертификати. Четете го заедно с операцията, която го е предизвикала: заявка за подписване, издадена от контекст, който не може да покаже подкана, ще се провали по този начин, дори когато ключът и сертификатът са напълно валидни. Мястото, от което да се започне, е операцията, която го е записала, а не хранилището на сертификати. Всяка промяна по котвите за доверие ще остави грешката точно там, където е била.
Затова приемете кода като причина да разгледате контекста на изпълнение и оторизацията. Ако го приемете като доказателство, че CA на шлюза не е надежден, ще отидете в грешната половина на проблема и промяната там няма да повлияе на грешката изобщо.
Поправяйте тясно, не широко
Започнете с инструкциите на собственика на връзката за регистрация или импортиране. Запишете версията на клиента, обхвата на профила, избраната идентичност и първата значима локална грешка, защото тези четири факта са това, което е нужно при предаване към поддръжката и от което зависи по-късно сравнение. Управляван профил или идентичност с апаратна поддръжка може да изисква администраторът или доставчикът да поправи предаването и никакво локално кликане не го замества.
Когато продуктът очаква одобрение от потребителя, потвърдете кой компонент го иска и одобрете само този достъп чрез поддържания поток. Когато компонентът няма как да покаже подкана в контекста, в който работи, осигуряването трябва да следва пътя, който доставчикът документира, а не диалог, измъкнат от друг терминален прозорец.
В по-стари съвети две промени се предлагат заедно и двете са твърде широки. Даването на достъп до частния ключ на всяко приложение разширява локалното използване на ключа далеч отвъд изискването, а настройката на сертификата на „Винаги доверен“ променя оценката на сертификатите за всичко на машината. Нито една от тях не изразява „тази одобрена VPN реализация, с тази предвидена идентичност“.
Проверете локално, преди да четете шлюза
След поправка потвърдете, че локалната операция успява, преди да тълкувате какъвто и да е отговор от другата страна. Ако подписването вече работи, последващо отхвърляне по име, верига или допускане на клиента е нов резултат, а не повторение, и принадлежи на друго решение с друг собственик.
Полезното предаване посочва кое от трите решения се е провалило и спира дотам. То никога не включва частния ключ и никога не нулира несвързани елементи на ключодържателя с надеждата, че чист лист ще помогне. Изградете тези два навика преди инцидента, а не по време на него, когато изкушението да опитате всичко наведнъж е най-силно. Тикет, който казва „престроихме ключодържателя“, не казва почти нищо на следващия читател за първоначалната повреда.