Сертификат 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 на основе пароля, телефону нужна предусмотренная аутентификация учётной записи плюс проверка сервера. Этот путь не оправдывает отправку одного общего закрытого ключа клиента всему парку, что представляет собой другой проект с гораздо худшим режимом отказа.

Завершите план с учётом обновления и отзыва: кто перевыпускает учётные данные клиента, как обновляется профиль и как отключается потерянный телефон. Запишите версию профиля и версии устройств, на которых вы проверяли, потому что именно эта запись делает следующую смену сертификата рутинной работой.