Android IKEv2: потребителският сертификат и CA вършат различни работи
Едното поле доказва кой е телефонът, другото решава на кой шлюз да се вярва. Профилът IKEv2 в Android ги държи отделно.
Екран за IKEv2 в Android, който иска едновременно потребителски сертификат и CA сертификат, изглежда като да иска едно и също два пъти. Не е така. IKEv2 удостоверява и двете страни в двете посоки в един обмен и телефонът играе различна роля във всяка посока: трябва да докаже кой е и да реши на кой шлюз вярва. Потребителският сертификат отговаря на първия въпрос, довереният CA — на втория, и нито един не замества другия.
Две посоки на удостоверяване в един обмен
IKEv2 изгражда контролен канал на два етапа. Първият договаря алгоритми и ключове; вторият, IKE_AUTH, носи по един AUTH товар от всяка страна заедно с нейната идентичност. Товарът е подпис или MAC върху обмена и се проверява срещу нещо, на което получателят вече вярва.
Шлюзът доказва себе си със своя сертификат; телефонът проверява веригата до корен, на който вярва, и че идентичността в сертификата съвпада с шлюза, който е искал да достигне. Телефонът доказва себе си със своите данни за достъп, а шлюзът ги проверява срещу CA, издал клиентския сертификат.
Това е целият механизъм зад двете полета. Потребителският сертификат е изявление на телефона за самия него; полето CA е изявление за това на кого ще вярва. Профил само с едното не може да завърши взаимно удостоверяване и повторните опити не променят това. Дори отказите изглеждат различно: без потребителски ключ телефонът не може да подпише, без котва на доверие не може да приеме сертификата на шлюза.
| Material | Role | What it cannot do |
|---|---|---|
| User certificate plus its private key | Proves possession of the enrolled client identity | Establish that the gateway is the right one |
| Trusted CA certificate | Validates the gateway chain under the intended identity checks | Prove the client's identity to the gateway |
| Expected gateway identity | Pins which server the phone accepts | Grant that user access to every private resource |
Какво изисква конструкторът на профили в Android
Конструкторът на профили IKEv2 в Android предлага всеки метод за удостоверяване отделно, а не като един режим сертификат. Методът с цифров подпис приема потребителски сертификат, частен ключ и корен CA на сървъра; другите приемат име и парола или предварително споделен ключ.
Прочетете този подпис внимателно, защото той описва механизма по-горе. В метода име и парола няма поле за частния ключ на потребителя, а в PSK няма поле за котвата на доверие на шлюза, защото тези методи доказват различни неща. Поставена в поле за сертификат, паролата дава профил, който се проваля при IKE_AUTH със съобщение, което не назовава нито едното, нито другото.
Документираният тип частен ключ за метода с цифров подпис е RSA. Меню с надпис IPsec или сертификат не означава поддръжка на ECDSA и профил, построен на това предположение, се проваля в API на платформата още преди мрежата.
Защо един публичен сертификат не е достатъчен
AUTH товарът е подпис върху обмена, направен с частния ключ на клиента. Публичният сертификат позволява на шлюза да провери подпис, но не прави нищо за телефона, който се нуждае от ключа, за да го създаде. Импорт само на .crt и оставяне на ключа назад е най-разпространената форма на този отказ.
Ключовата инфраструктура на Android го отразява. Изборът на клиентска идентичност минава през KeyChain, който изисква достъп до съответния частен ключ, не само запис за сертификат. Пакет за записване или процес за управление на устройства, който инсталира двойката заедно, е нормалният начин да получите използваема идентичност; ръчното копиране на файл обикновено не е.
Двата елемента в профила не са набор от сертификати и негово копие. Единият е двойка ключове, с която платформата трябва да може да подписва, другият е котва на доверие, с която сравнява. Проверявайте ги като два отделни факта: може ли този профил да подписва и знае ли на кого да вярва?
Котвите на доверие принадлежат на приложението, не на телефона
Инсталиран в хранилището на потребителя корен не кара всяко приложение да му вярва: от Android 7 приложението трябва да го избере чрез конфигурацията за мрежова сигурност, а преди това издание CA, инсталирани от потребителя, се приемаха много по-широко. Конфигурацията на доверие може да се различава, а VPN клиент, който сам управлява материала си на доверие, може изобщо да не поглежда хранилището. Затова един и същ CA файл може да работи в един клиент и да изглежда пренебрегнат в друг.
Следват два модела на собственост. Управляван от системата профил използва инсталирането на сертификати на устройството или записване от администратор и после сочи към желания CA. Управляван от приложението VPN държи свой материал и свой документиран импорт, който може да е напълно отделен от екрана с настройки на Android. Там се поправя и скъсана верига.
Решете в кой модел сте, преди да импортирате нещо, и после потвърдете избора на доверие на активния профил. Ако инструкциите на оператора и менюто на клиента се разминават, за тази инсталация печели документираното поведение на клиента, но CA трябва да идва от оператора по канал, който можете да проверите. Името на файла не е доказателство кой го е издал.
Първо режимът, после файловете
Режимът със сертификат изисква двойка ключове на клиента, издаващия CA от страна на шлюза, котва на доверие за сертификата на шлюза и очакване каква идентичност трябва да носи той. Име и парола заменя двойката с данни за достъп, но запазва изискването за доверие към шлюза. PSK заменя и двете с обща тайна и променя модела на доверие, вместо да го опростява.
Каквото и да изберете, оставете нормалната проверка включена. Опцията без проверка премахва проверката, за която съществува полето CA, и не поправя липсваща котва на доверие. Същото важи за приемането на всеки сървърен сертификат, защото връзката работи и без него.
После проверете на правилното място: импортирайте материала, свържете се веднъж и в детайлите на връзката потвърдете, че идентичността на шлюза е очакваната и че профилът съобщава метода, който сте имали предвид. Успешна връзка с грешен метод е конфигурация, която още не разбирате, и ще се провали, когато операторът затегне политика.