Инсталирахте сертификата, той се появява в Keychain Access с приятелско име, а списъкът за избор на идентичност на VPN клиента все още е празен. Клиентът не търси сертификат. Той търси идентичност: сертификат, сдвоен с частния ключ, който може да докаже притежание, съхранен там, където на клиента е разрешено да чете.

Това, което клиентът иска, е идентичност

Сигурностната рамка на Apple третира сертификата и идентичността като различни обекти. Сертификатът е публични данни. Идентичността е този сертификат плюс неговия частен ключ и само идентичността може да завърши предизвикателство. Довереният CA сертификат междувременно позволява на клиента да оцени издател; той не прави машината притежател на издадено клиентско удостоверение.

ItemWhat it can doWhat it cannot do
CA or server certificateValidate the gateway's chainAuthenticate this client
Client certificate without keyNothing for authenticationProve possession of anything
Identity (cert plus key)Answer the authentication challengeGuarantee the gateway accepts it

Ето защо импортирането на файл .cer никога не създава използваема идентичност на клиент. Файлът носи само публичен материал и никакво преименуване или доверяване не го прави двойка ключове.

Три причини списъкът да остане празен

Първата е липсващ частен ключ, което означава, че процесът на регистрация или импорт не е предоставил такъв. Втората е хранилище, което клиентът не проверява: профил, ограничен до потребител, търси в ключодържателя на потребителя, а елемент, поставен в системно хранилище, може да е невидим за него. Третата е несъответствие на предназначение или политика, при което сертификатът съществува, но не е валиден за удостоверяване на клиент според правилата на внедряването.

security find-identity -v -p ssl-client

Това изброява идентичностите, които системата смята за валидни за удостоверяване на клиент. Ако броят е нула, проблемът е преди VPN клиента и никаква редакция на профила няма да го поправи. Ако идентичността се появи тук, но не в клиента, разликата е в хранилището или обхвата на клиента.

Къде живее частният ключ и кой може да го използва

Когато импортирате идентичност чрез Keychain Access, диалогът за импорт предлага ключодържател по местоназначение. Кое местоназначение е правилно зависи от клиента и от това дали профилът е ограничен до потребител или до устройство. Старият отговор, който препоръчва системния ключодържател, не е универсално правило и копирането на елементи между хранилища не е ремонт.

System Roots е колекция за доверие. Поставянето на сертификат там променя кои издатели системата доверява; то не създава частен ключ и не е хранилище за идентичности. Преместването на несвързани сертификати, за да се напълни списък за избор, е видът ремонт, който оставя машината с постоянно разширен набор за доверие.

Достъпът до частния ключ е отделна контрола. Даването на всяко приложение разрешение да използва ключа решава проблема с избора на един клиент и предоставя същата възможност на всичко останало на машината. Дайте го на клиента, който се нуждае от него, и проверете дали ключът е хардуерно защитен или маркиран като неекспортируем; ако е така, трябва да се използва поддържаният доставчик, а не експортирано копие.

Как профилът сочи към удостоверението

В управлявана вградена IKEv2 конфигурация профилът препраща към полезния товар на удостоверението си чрез PayloadCertificateUUID. Идентичността, към която има препратка, и начинът, по който е предоставена, са това, което има значение; редактирането на показвано име в профила не поправя препратка, която сочи към грешен полезен товар или към такъв, който никога не е доставил ключ.

Доставчик от трета страна може да използва напълно различен механизъм за избор, например собствено хранилище или системна подкана. Четете документацията на този доставчик, вместо да пренасяте допусканията за вградения профил, и проверявайте препратката в действително инсталирания профил, а не в черновата в конзолата за управление.

Изборът и приемането са отделни етапи

Попълнен списък за избор означава, че клиентът може да намери и използва идентичност. Това не казва нищо за това дали шлюзът ще я приеме. Сървърът все още проверява издателя, прозореца на валидност, статуса на отмяна и съпоставянето на това удостоверение с акаунт.

Тествайте двата етапа изрично, в този ред. Потвърдете, че идентичността се предлага, свържете се и след това накарайте собственика на шлюза да потвърди кое удостоверение е представено и кое правило за съпоставяне го е използвало. Ако клиентът предлага идентичност, а сървърът я отхвърля, останалата работа е от страната на сървъра. Преинсталирането на сертификата на Mac няма да промени този резултат, колкото и пъти да се повтори.

Подобни статии