Пријава на 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 имплементација, користећи овај предвиђени идентитет“.
Провери локално пре него што прочиташ пролаз
Након поправке потврди да локална операција успева пре него што протумачиш било какав одговор са друге стране. Ако потписивање сада ради, касније одбијање имена, ланца или пријема клијента нов је резултат, а не понављање, и припада другој одлуци са другим одговорним.
Корисна предаја именује која од три одлуке није успела и ту се зауставља. Никада не укључује приватни кључ и никада не ресетује неповезане ставке привеска у нади да ће чист почетак помоћи. Те две навике успостави пре инцидента, а не током њега, када је искушење да се све проба одједном најјаче. Тикет који каже „привезак је поново изграђен“ следећем читаоцу не каже готово ништа о изворном квару.