Сертыфікат IKEv2 і SAN: чаму праверка ідэнтычнасці не праходзіць

Ваш сертыфікат будуецца да даверанага CA, даты ў парадку, але партнёр усё роўна адмаўляецца завяршыць фазу 1 з памылкай ідэнтычнасці. Дасяжнасць і сапраўдны подпіс — гэта толькі палова таго, што правярае кліент IKEv2. Другая палова — ці з'яўляецца чаканая ідэнтычнасць у сертыфікаце ў патрэбным полі, і гэтае чаканне задае профіль, а не імя файла сертыфіката.

Сімптом заўсёды адной формы

Профіль злучэння змяняюць з імя хоста на IP-адрас або абнаўляюць з сертыфіката з DNS-іменем на той, што нясе толькі адрасы, і тунэль спыняе ўзгадненне. У сеткавым шляху нічога не змянілася. Кліент дасягае партнёра, атрымлівае сертыфікат і адхіляе ідэнтычнасць партнёра, бо ідэнтыфікатар, які ён чакаў, не прадстаўлены ў полі, якое ён прымае. Абнаўленні — звычайная прычына, бо заменны сертыфікат часта паходзіць з іншага шаблона, чым той, які ён замяняе.

Потым абодва бакі запісваюць нешта бескарыснае, таму збой звычайна паведамляюць як праблему сертыфіката. Журнал кліента можа назваць ідэнтычнасць, якую ён хацеў, і гэтае імя — патрэбная вам падказка, а не дата заканчэння.

Супастаўляйце тып ідэнтыфікатара, а не толькі значэнне

dNSName SAN і iPAddress SAN — розныя полі з рознымі правіламі супастаўлення, таму сертыфікат з 203.0.113.10 у якасці DNS-радка не задаволіць кліента, які чакае IP-ідэнтычнасць. Сучасныя правяральнікі пераважна ігнаруюць агульнае імя, таму зручная этыкетка ў дэталях сертыфіката нічога не даказвае пра тое, што супадзе. Калі падчас пошуку няспраўнасці імя хоста замянілі адрасам, мяркуйце, што чаканая ідэнтычнасць перамясцілася разам з ім, пакуль не праверыце. Параўноўвайце радок у профілі з радком у SAN пасімвальна, бо дастаткова кропкі ў канцы або лішняга прабелу.

Сімвалы падстаноўкі — зручнасць толькі для DNS, і яны маюць свае правілы супастаўлення, што яшчэ адна прычына, чаму профіль на аснове IP не павінен на іх спадзявацца.

Знайдзіце, дзе кожны кліент захоўвае чаканне

У strongSwan значэнне, якое параўноўваецца з сертыфікатам, бярэцца з налады ідэнтычнасці партнёра: rightid у класічнай канфігурацыі або id раздзела аддаленага злучэння ў swanctl. Дакументацыя пра сумяшчальнасць з Apple IKEv2 тут карысная, бо выкладае ўмовы ідэнтычнасці, якія выкарыстоўвае кліент з профілем, і гэтыя ўмовы тлумачаць клас разыходжанняў, які ў сетцы выглядае выпадковым.

Профілі канфігурацыі Apple нясуць поле аддаленага ідэнтыфікатара, і значэнне там — гэта тое, што правярае кліент, а не адрас сервера ў наладах злучэння. Кліенты Windows і прылад маюць кожны сваё поле са сваім прадвызначаным значэннем, і прадвызначанае часта ідзе за адрасам, які вы ўвялі. Калі два полі разыходзяцца, перамагае тое, якое кліент фактычна чытае, і яно рэдка бывае тым, што вы рэдагавалі.

Выпраўце профіль або сертыфікат свядома

Аглядзіце сертыфікат партнёра ўхваленымі сродкамі і пералічыце запісы SAN з іх тыпамі, перш чым што-небудзь мяняць. Гэты агляд не патрабуе прыватнага ключа і загрузкі і вырашае пытанне за секунды. Калі разгортванне мае на ўвазе адну DNS-ідэнтычнасць, сертыфікат павінен несці яе як запіс dNSName, а калі адрас — сертыфікату патрэбен запіс iPAddress менавіта для гэтага адраса.

Калі сертыфікат няправільны, запытайце ў аператара выпраўлены з канкрэтным чаканым ідэнтыфікатарам. Калі няправільны профіль, выпраўце профіль і пакіньце сертыфікат як ёсць. Адключэнне праверкі ідэнтычнасці прыбірае памылку і выдаляе праверку таго, што тунэль размаўляе з патрэбным партнёрам.

Дакументуйце чаканую ідэнтычнасць для кожнай платформы кліента, бо значэнне, якое адзін кліент выводзіць аўтаматычна, на іншым можа спатрэбіцца ўказаць яўна.

Дайце запыту на абнаўленне чатыры факты

Запішыце чаканы ідэнтыфікатар і яго тып, запісы SAN, якія фактычна мае бягучы сертыфікат, кліент і версію, што выконваюць праверку, і дакладны тэкст памылкі. Запыт на абнаўленне, пабудаваны з гэтых чатырох радкоў, атрымае правільны сертыфікат з першага разу, а не чарговы з такім знаёмым імем файла.