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