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