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, които текущият сертификат действително има, клиента и версията, които извършват проверката, и точния текст на грешката. Заявка за подновяване, изградена от тези четири реда, получава правилния сертификат от първия път, вместо още един със същото познато име на файл.