Mac IKEv2 ECDSA: кой тип сертификат принадлежи на клиента?
На Mac ECDSA256 в настройките на IKEv2 описва локалния сертификат за идентичност, а не шлюза или подписа на издателя. Прочетете всяка роля, преди да избирате.
В macOS изборът на ECDSA в настройка на клиент IKEv2 отговаря на тесен въпрос: кой сертификат доказва идентичността на Mac. Той не описва сертификата на шлюза, подписа, с който е издаден клиентският сертификат, нито предложението за криптиране на тунела. Отнасянето към тези четири роли като към един въпрос за съвместимост е начинът, по който правилна локална настройка бива обвинявана за несъответствие от страна на сървъра. Решението е малко, но доказателствата за него трябва да са точни.
Полето именува един сертификат: локалната идентичност
Network Extension API на Apple предоставя тип сертификат за клиентските идентификационни данни, включително NEVPNIKEv2CertificateType.ECDSA256, документиран като тип сертификат ECDSA p-256. Свойството се отнася за сертификата, подаден чрез identityReference или identityData.
Това означава, че решението е за сертификата, който Mac представя, плюс частния ключ към него. Изберете типа, който съответства на публичния ключ на този краен сертификат, и подайте идентичността чрез поддържания механизъм. Ако Mac няма използваем частен ключ за идентичността, изборът на тип не може да спаси връзката.
Управляваните профили вземат същото решение чрез CertificateType в payload на IKEv2, съчетан с препратка към сертификат като PayloadCertificateUUID. Тези полета имат предварителни условия и схема за целевата версия на ОС; голо стойност на типа, копирано в профил, не се инсталира, а прозорецът с настройки може да не показва всяка опция на API. Проверете предварителните условия на payload за тази версия преди разгръщане.
Решавайте по роля, не по етикета на сертификата
Прочетете полето, което ще промените, и се запитайте към кой сертификат сочи. Етикетите в прегледа на сертификати смесват субекта, издателя и алгоритъма на подписа, а само един от тях принадлежи на избора на клиентска идентичност.
| 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. Накрая се свържете и прочетете къде спира ръкостискането. Отказ преди размяната на идентичности сочи встрани от тази настройка; отказ при валидиране на партньора сочи към страната на шлюза.
Запишете избрания тип, препратката към идентичността и субекта на сертификата на шлюза в бележките за разгръщане. Следващата актуализация на профила може да промени всяко от тях, а три именувани стойности се сравняват по-бързо от екранна снимка на панел с настройки.