Најава на 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 и не кажува ништо за ланците на сертификати. Читајте го заедно со операцијата што го создала: барањето за потпис издадено од контекст што не може да прикаже барање ќе не успее така дури и кога клучот и сертификатот се сосема валидни. Почетокот е операцијата што го запишала, не складиштето на сертификати. Сето што ќе смените околу сидрата на доверба ќе ја остави грешката точно каде што била.
Затоа третирајте го кодот како причина да се испитаат контекстот на извршување и авторизацијата. Третирањето како доказ дека CA на портата не е доверлив ве носи во погрешната половина од проблемот, а промената што ќе ја направите таму воопшто нема да влијае на грешката.
Поправајте тесно, не широко
Започнете со упатствата за запишување или увоз на сопственикот на врската. Забележете ја верзијата на клиентот, опфатот на профилот, избраниот идентитет и првата релевантна локална грешка, бидејќи токму тие четири факти му се потребни на предавањето на поддршката и од нив зависи подоцнежната споредба. Управуван профил или идентитет поддржан од хардвер може да бара администраторот или давателот да го поправат предавањето, и ниту една количина локално кликање не го заменува тоа.
Каде производот очекува одобрување од корисникот, потврдете која компонента го бара и одобрете го само тој пристап преку поддржаниот тек. Каде компонентата нема начин да подигне барање во контекстот во кој работи, обезбедувањето мора да го следи патот што го документира добавувачот, а не дијалог извлечен од друг прозорец на терминал.
Две промени се спакувани заедно во постари совети, и двете се прешироки. Давањето пристап до приватниот клуч на секоја апликација ја проширува локалната употреба на клучот далеку над барањето, а поставувањето на сертификатот на Always Trust ја менува проценката на сертификати за сите на машината. Ниту една не изразува „оваа одобрена VPN имплементација, користејќи го овој предвиден идентитет“.
Проверете локално пред да ја читате портата
По поправката потврдете дека локалната операција успева пред да протолкувате каков било одговор од другата страна. Ако потпишувањето сега работи, подоцнежното одбивање на име, ланец или прием на клиент е нов резултат, а не повторување, и припаѓа на друга одлука со друг одговорен.
Корисно предавање именува која од трите одлуки не успеала и застанува таму. Тоа никогаш не го вклучува приватниот клуч и никогаш не ресетира неповрзани елементи на привезокот со клучеви во надеж дека чиста состојба ќе помогне. Воспоставете ги тие две навики пред инцидентот, а не за време на него, кога искушението сето да се проба одеднаш е најсилно. Тикетот што вели „привезокот е преизграден“ на следниот читател не му кажува речиси ништо за првобитната дефект.