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. На крајот поврзете се и прочитајте каде запира ракувањето. Неуспех пред размената на идентитети упатува подалеку од оваа поставка; неуспех при валидација на партнерот упатува на страната на портата.
Запишете го избраниот тип, референцата за идентитет и субјектот на сертификатот на портата во белешките за распоредување. Следното ажурирање на профилот може да промени било кое од нив, а три именувани вредности се споредуваат побрзо од слика од екранот на панел со поставки.