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

Завершіть план з огляду на оновлення та відкликання: хто перевипускає облікові дані клієнта, як оновлюється профіль і як відключається втрачений телефон. Запишіть версію профілю та версії пристроїв, на яких ви перевіряли, бо саме цей запис робить наступну заміну сертифіката рутинною роботою.