Поставување на 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 заснован на лозинка, на телефонот му треба предвидената автентикација на сметката плус валидација на серверот. Тој пат не оправдува испраќање на еден заеднички приватен клуч на клиентот до целата флота, што е различен дизајн со многу полош режим на откажување.

Завршете го планот имајќи ги на ум обновувањето и отповикувањето: кој повторно ги издава акредитивите на клиентот, како се ажурира профилот и како се отсекува изгубен телефон. Запишете ја верзијата на профилот и верзиите на уредите спрема кои сте валидирале, бидејќи токму тој запис ја прави следната промена на сертификат рутинска работа.