Android IKEv2: корисничкиот сертификат и CA вршат различни работи

Екранот за IKEv2 во Android што бара истовремено кориснички сертификат и CA сертификат изгледа како да го бара истото двапати. Не е така. IKEv2 ги проверува двете страни во двете насоки во една размена, а телефонот има различна улога во секоја насока: мора да докаже кој е и да одлучи на која порта ѝ верува. Корисничкиот сертификат одговара на првото прашање, доверливиот CA на второто, и ниеден не го заменува другиот.

Две насоки на проверка во една размена

IKEv2 гради контролен канал во две фази. Првата се договара за алгоритми и клучеви; втората, IKE_AUTH, носи по еден AUTH товар од секоја страна заедно со нејзиниот идентитет. Товарот е потпис или MAC врз размената и се проверува против нешто во што примачот веќе верува.

Портата се докажува со сопствениот сертификат, а телефонот го проверува синџирот до коренот што го прифаќа и проверува дали идентитетот во сертификатот одговара на портата до која сакал да стигне; телефонот се докажува со своите податоци, а портата ги проверува против CA што го издала клиентскиот сертификат.

Тоа е целиот механизам зад двете полиња. Корисничкиот сертификат е изјава на телефонот за себе; полето CA е изјава за тоа кому ќе верува. Профил со едното без другото не може да ја заврши заемната проверка, а повторувањето тоа не го менува. Дури и грешките изгледаат поинаку: без кориснички клуч телефонот воопшто не може да потпише, без сидро на доверба не може да го прифати сертификатот на портата.

Што бара градителот на профили во Android

Градителот на IKEv2 профили во Android го нуди секој метод на проверка одделно, а не како еден режим на сертификат. Методот со дигитален потпис зема кориснички сертификат, приватен клуч и коренски CA на серверот; останатите земаат корисничко име и лозинка или однапред споделен клуч.

Прочитајте го тој потпис внимателно, зашто го опишува механизмот погоре. Во методот со корисничко име и лозинка нема поле за приватниот клуч, а во PSK нема поле за сидрото на доверба на портата, зашто тие методи докажуваат различни работи. Лозинка ставена во поле за сертификат дава профил што паѓа на IKE_AUTH со порака што не именува ниедно од двете.

Документираниот тип на приватен клуч за методот со дигитален потпис е RSA. Менито означено IPsec или сертификат не значи поддршка за ECDSA, а профилот изграден на таа претпоставка паѓа на API на платформата уште пред мрежата да влезе во игра.

Зошто само јавен кориснички сертификат не е доволен

AUTH товарот е потпис врз размената направен со приватниот клуч на клиентот. Јавниот сертификат ѝ овозможува на портата да провери потпис, но не прави ништо за телефонот, на кого му треба клучот за да го создаде. Внесувањето само на .crt и оставањето на клучот зад себе е најчестата форма на оваа грешка.

Инфраструктурата на клучеви во Android го одразува тоа: изборот на клиентски идентитет оди преку KeyChain, што бара пристап до соодветниот приватен клуч, не само запис за сертификат. Регистрациски пакет или процес за управување со уреди што го инсталира парот заедно е вообичаениот начин да се добие употреблив идентитет; рачното копирање датотека обично не е.

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

Сидрата на доверба им припаѓаат на апликацијата, не на телефонот

Корен инсталиран во корисничкото складиште не прави секоја Android апликација да му верува: од Android 7 апликацијата мора да го избере тоа преку својата конфигурација за мрежна безбедност, а пред тоа издание CA инсталирани од корисникот се прифаќаа многу пошироко. Конфигурацијата на доверба може да се разликува, а VPN клиент што самиот управува со својот материјал за доверба може воопшто да не го погледне складиштето. Затоа истата CA датотека може да работи во еден клиент и да изгледа игнорирана во друг.

Оттука следуваат два модели на сопственост. Профил управуван од системот ја користи инсталацијата на сертификати на уредот или регистрацијата на администратор и потоа упатува на предвидениот CA. VPN управуван од апликацијата го држи својот материјал за доверба и своето документирано внесување, што може да биде целосно одвоено од екранот за поставки на Android. Таму се поправа и прекинат синџир.

Одлучете во кој модел сте пред да внесете нешто, а потоа потврдете го изборот на доверба на активниот профил. Ако упатствата на операторот и менито на клиентот не се совпаѓаат, за тоа инсталирање победува документираното однесување на клиентот, но CA мора сепак да дојде од операторот преку канал што можете да го проверите. Името на датотека не е доказ за тоа кој ја издал.

Прво режимот, потоа датотеките

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

Што и да изберете, оставете ја нормалната проверка вклучена. Опцијата без проверка ја отстранува проверката за која постои полето CA; таа не поправа сидро на доверба што недостасува. Истото важи за прифаќање на кој било серверски сертификат затоа што врската работи и без него.

Потоа проверете на вистинското место: внесете го материјалот, поврзете се еднаш и во деталите за врската потврдете дека идентитетот на портата е очекуваниот и дека профилот го известува методот што го имавте на ум. Успешна врска со погрешен метод е конфигурација што сè уште не ја разбирате и ќе падне кога операторот ќе заостри политика.