IKEv2 сертификат на iPhone-у: ручна или управљана регистрација

Избор RSA само зато што алатка за сертификате пролаза користи њега као подразумевано је одлука донета пре питања које је важно: како ће ови iPhone бити регистровани? Веза коју корисник сам уноси и профил конфигурације који доставља управљање излажу различите поставке, а неке опције сертификата постоје само на једном од тих путева. Поставите редослед исправно и план сертификата постаје кратак; погрешите и издаћете акредитив који телефон неће користити. Третирајте кораке испод као низ, јер сваки сужава изборе доступне следећем.

Први корак: изаберите пут регистрације

Ручно подешавање значи да корисник уноси адресу сервера, бира метод аутентификације и пружа све акредитиве које интерфејс дозвољава. Управљана регистрација значи да профил носи адресу, идентификаторе и референцу на товар са акредитивима. Управљани пут може да изрази комбинације које ручни екран не може, зато одлука о сертификату мора да дође после овог избора, а не пре њега.

Оба пута могу да аутентификују телефон. Разликују се по томе шта можете да конфигуришете и коме припада идентитет, зато свесно изаберите један уместо да мешате управљани профил са ручним уносом акредитива.

Други корак: изаберите алгоритме за изабрани пут

За ручно конфигурисане iPhone, белешке strongSwan о интероперабилности са iOS препоручују RSA серверски сертификат, јер ручни клијент можда неће прихватити ECDSA серверски сертификат; исте белешке macOS третирају одвојено. Читајте то као смерницу за подржани скуп клијената, а не као трајни закон о Apple уређајима. Управљани профил има више простора: може експлицитно да изабере тип сертификата, укључујући ECDSA идентитет клијента, када товар и пролаз то обоје подржавају.

Валидирајте iOS верзије које заиста подржавате пре него што било шта примените. Лабораторијски телефон на најновијој верзији не описује флоту која укључује старије уређаје, а алгоритам који ради у лабораторији ипак може да закаже на најстаријем телефону на терену. Узмите опсег верзија из управљања уређајима, а не из памћења. Ако флота обухвата неколико верзија, прво тестирајте најстарију, јер је тамо ручни интерфејс најограниченији.

Трећи корак: читајте поља профила као одвојене ствари

Неколико кључева сличног имена описује различите објекте. Даљинска адреса је домаћин који телефон позива. Даљински идентификатор је IKE идентитет који се очекује да пролаз представи. Референца на сертификат у товару показује на акредитив клијента, а поље типа сертификата бира тип који се користи за машинску аутентификацију преко IKEv2. Ниједно од тога није алгоритам потписа CA, иако се речи преклапају.

Apple референца за IKEv2 товар наводи RSA као подразумевани тип сертификата са експлицитним ECDSA варијантама и повезује кључ имена издаваоца са одређеним поставкама аутентификације. Читајте те везе у референци за метод који сте изабрали, уместо да копирате један кључ из радног распоређивања.

Четврти корак: ускладите идентитет пролаза са његовим сертификатом

Користите експлицитно име пролаза, на пример vpn.example.com и ставите одговарајуће алтернативно име субјекта у серверски сертификат. Упутство strongSwan за Apple такође очекује проширену употребу кључа за аутентификацију сервера. Избор RSA или ECDSA не мења ништа од тога: алгоритам не може да поправи неслагање имена, EKU који недостаје или непотпуни ланац.

Дистрибуција сидра поверења је одвојен задатак од тврдње идентитета. Телефону је потребан ланац сертификата који може да валидира, и мора бити конфигурисан да очекује име које сте заиста ставили у сертификат.

Успешно повезивање друге платформе доказ је о правилима валидације те платформе, а не дозвола да олабавите правила телефона. Држите провере идентичним међу клијентима, осим ако имате документован разлог да се разликују.

Пети корак: одвојите идентитет клијента од поверења у CA

Сертификат клијента и његов приватни кључ нису исти објекат као CA сертификат коме телефон верује. Паковање CA сертификата у PKCS#12 идентитет не инсталира га аутоматски као сидро поверења на сваком подржаном уређају, зато третирајте дистрибуцију поверења као посебан корак са сопственом провером.

Ако дизајн уместо тога користи EAP заснован на лозинци, телефону су потребни предвиђена аутентификација налога и валидација сервера. Тај пут не оправдава слање једног заједничког приватног кључа клијента целој флоти, што је други дизајн са много горим режимом отказа.

Завршите план имајући на уму обнову и опозив: ко поново издаје акредитиве клијента, како се профил ажурира и како се изгубљени телефон одсеца. Забележите верзију профила и верзије уређаја према којима сте валидирали, јер тај запис чини следећу замену сертификата рутинском променом.