Mac VPN сертификат: зашто избор идентитета остаје празан
Клијенту је потребан сертификат са приватним кључем, у складишту које чита. Прво проверите идентитет, а затим да ли га пролаз прихвата.
Инсталирали сте сертификат, он се појављује у 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-у неће променити тај исход, колико год пута се понови.