SAN на сертификатот IKEv2: зошто проверката на идентитетот не успева

Вашиот сертификат е поврзан со доверлива 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 записите што тековниот сертификат навистина ги има, клиентот и верзијата што ја вршат проверката и точниот текст на грешката. Барање за обновување изградено од овие четири реда првиот пат добива правилен сертификат, наместо уште еден со истото познато име на датотека.