Mac IKEv2 ECDSA: який тип сертифіката належить клієнту?
На Mac параметр ECDSA256 у налаштуваннях IKEv2 описує локальний сертифікат ідентичності, а не шлюз чи підпис видавця. Прочитайте кожну роль перед вибором.
У macOS вибір ECDSA в налаштуванні клієнта IKEv2 відповідає на вузьке питання: який сертифікат доводить ідентичність Mac. Він не описує сертифікат шлюзу, підпис, яким видано клієнтський сертифікат, або пропозицію шифрування для тунелю. Розгляд цих чотирьох ролей як одного питання сумісності — це те, через що правильне локальне налаштування звинувачують у невідповідності на боці сервера. Рішення невелике, але докази, на яких воно ґрунтується, мають бути точними.
Поле називає один сертифікат: локальну ідентичність
Network Extension API від Apple надає тип сертифіката для облікових даних клієнта, зокрема NEVPNIKEv2CertificateType.ECDSA256, документований як тип сертифіката ECDSA p-256. Властивість застосовується до сертифіката, переданого через identityReference або identityData.
Це означає, що рішення стосується сертифіката, який пред'являє Mac, і пов'язаного з ним закритого ключа. Виберіть тип, що відповідає відкритому ключу цього кінцевого сертифіката, і передайте ідентичність підтримуваним механізмом. Якщо в Mac немає придатного закритого ключа для ідентичності, вибір типу не врятує з'єднання.
Керовані профілі ухвалюють те саме рішення через CertificateType корисного навантаження IKEv2 разом із посиланням на сертифікат, наприклад PayloadCertificateUUID. Ці поля мають передумови й схему для цільової версії ОС; голе значення типу, скопійоване в профіль, не встановлюється, а вікно налаштувань може не показувати кожен параметр API. Перевірте передумови корисного навантаження для цієї версії перед розгортанням.
Вирішуйте за роллю, а не за етикеткою сертифіката
Прочитайте поле, яке збираєтеся змінити, і запитайте, на який сертифікат воно вказує. Позначки в переглядачі сертифікатів змішують суб'єкт, видавця та алгоритм підпису, і лише одна з них стосується вибору ідентичності клієнта.
| What you inspected | What it controls | Does it choose the Mac certificate type? |
|---|---|---|
| Client leaf public key | The identity the Mac presents | Yes, this is the field's subject |
| Issuer signature algorithm | How the client certificate was signed | No |
| Gateway certificate | What the Mac validates as the peer | No, check it separately |
| IKE and ESP proposals | Algorithms for the tunnel | No, separate proposal settings |
Якщо переглядач сертифікатів показує підпис ECDSA від CA, це описує ключ підпису видавця. Власний ключ клієнта може досі бути RSA, і поле типу має йти за ключем клієнта, а не за рядком підпису. Саме це одне непорозуміння пояснює багато звітів "ECDSA налаштовано, але з'єднання не працює". Порівняйте тип ключа в кінцевому сертифікаті з типом, вибраним у профілі, перш ніж щось змінювати.
Рішення стає простішим, коли кінцевий сертифікат визначено: ECDSA256 для клієнтського ключа p-256, інший підтримуваний тип для іншого ключа. Якщо клієнтський сертифікат і його ключ не збігаються, виправте цю пару до зміни профілю VPN.
Сертифікат шлюзу — окреме рішення
Шлюз пред'являє власний сертифікат, і Mac перевіряє його щодо якоря довіри та очікуваного імені. Чи використовує цей сертифікат ECDSA, RSA або інший тип ключа — це властивість сервера, а не налаштування ідентичності клієнта.
Локальна підтримка клієнтського сертифіката ECDSA не доводить, що будь-який сертифікат шлюзу, крива чи конфігурація автентифікації сервера будуть сумісні. Перевірте ідентичність сервера, його ланцюжок і метод автентифікації IKE як окремі вхідні дані та протестуйте з профілем, який справді буде розгорнуто.
Якщо проблема в сертифікаті шлюзу, симптом зазвичай з'являється під час перевірки партнера, а не під час вибору ідентичності. Прочитайте етап збою до зміни типу клієнта, бо збій довіри й невідповідність клієнтського ключа не мають спільного виправлення.
Підпис видавця та група узгодження ключів — не тип клієнта
X.509 тримає відкритий ключ суб'єкта та підпис видавця в різних полях. Інформація про відкритий ключ суб'єкта описує ключ у сертифікаті; алгоритм підпису описує ключ CA і операцію підписування. Лише перше відповідає налаштуванню типу сертифіката.
Пропозиції IKE і Child SA — інша вісь. Тип сертифіката ECDSA не є вибором шифрування ESP, і зміна групи узгодження ключів не вибирає тип сертифіката. У профілі можуть бути слушні пропозиції й неправильний тип ідентичності, або правильний тип ідентичності й пропозиція, яку партнер відхиляє.
Тримайте три рядки окремо в журналі змін: сертифікат і ключ ідентичності, вхідні дані довіри шлюзу й алгоритми пропозицій. Об'єднання їх в одну нотатку "налаштування шифрування" робить наступний збій неможливим для атрибуції.
Перевірте рішення за налаштованими полями
Перевірте ідентичність, на яку профіль справді посилається, потім переконайтеся, що сертифікат за цим посиланням має очікуваний відкритий ключ і придатний закритий ключ. Показаний в інтерфейсі тип, зазначений сертифікат і ключ на пристрої мають збігатися.
Далі підтвердьте вхідні дані шлюзу: очікуване ім'я сервера, якір довіри й метод автентифікації IKE. Нарешті підключіться й прочитайте, де зупиняється рукостискання. Збій до обміну ідентичностями вказує вбік від цього налаштування; збій під час перевірки партнера вказує на бік шлюзу.
Запишіть вибраний тип, посилання на ідентичність і суб'єкт сертифіката шлюзу в нотатках про розгортання. Наступне оновлення профілю може змінити будь-що з них, і три названі значення порівнювати швидше, ніж знімок екрана панелі налаштувань.