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 доверять ему: с Android 7 приложение должно выбрать это в своей конфигурации сетевой безопасности, а до той версии установленные пользователем CA принимались гораздо шире. Конфигурация доверия может различаться, и VPN-клиент, который сам управляет своим материалом доверия, может вообще не заглядывать в хранилище. Поэтому один и тот же файл CA может работать в одном клиенте и выглядеть проигнорированным в другом.
Отсюда две модели владения. Профиль под управлением системы использует установку сертификатов устройства или регистрацию администратора и затем ссылается на нужный CA. VPN под управлением приложения хранит свой материал доверия и свой документированный импорт, который может быть полностью отдельным от экрана настроек Android. Там же чинят и разорванную цепочку.
Определите, в какой модели вы находитесь, прежде чем что-то импортировать, и затем подтвердите выбор доверия активного профиля. Если инструкции оператора и меню клиента расходятся, для этой установки побеждает документированное поведение клиента, но CA всё равно должен приходить от оператора по каналу, который вы можете проверить. Имя файла не доказывает, кто его выдал.
Сначала режим, потом файлы
Режим сертификата требует пары ключей клиента, издающего CA на стороне шлюза, якоря доверия для сертификата шлюза и ожидания того, какую идентичность он должен нести. Имя и пароль заменяют пару ключей учётными данными, но сохраняют требование доверия к шлюзу. PSK заменяет оба общим секретом и меняет модель доверия, а не упрощает её.
Что бы вы ни выбрали, оставьте обычную проверку включённой. Опция без проверки убирает ту проверку, для которой существует поле CA; отсутствующий якорь доверия она не исправляет. То же касается принятия любого сертификата сервера потому, что соединение работает и без него.
Затем проверяйте в правильном месте: импортируйте материал, подключитесь один раз и в деталях соединения подтвердите, что идентичность шлюза ожидаемая и профиль сообщает задуманный метод. Успешное соединение с неверным методом это конфигурация, которую вы ещё не понимаете, и она откажет, когда оператор ужесточит политику.