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