SAN сертификата IKEv2: почему проверка идентичности не проходит

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

Симптом всегда одной формы

Профиль подключения меняют с имени хоста на IP-адрес или обновляют с сертификата, содержавшего DNS-имя, на сертификат, содержащий только адреса, итуннель перестаёт согласовываться. В сетевом пути ничего не изменилось. Клиент достигает партнёра, получает сертификат и отклоняет идентичность партнёра, потому что идентификатор, который ему велели ожидать, не представлен в принимаемом им поле. Обновления — обычный триггер, так как заменяющий сертификат часто выпускается по другому шаблону, чем заменяемый.

Затем обе стороны пишут в журнал что-то бесполезное, поэтому сбой обычно регистрируют как проблему с сертификатом. В журнале клиента может быть названа нужная идентичность, и это имя — нужная вам подсказка, а не дата истечения.

Сопоставляйте тип идентификатора, а не только значение

SAN типа dNSName и SAN типа iPAddress — разные поля с разными правилами сопоставления, поэтому сертификат с 203.0.113.10 в виде строки DNS не удовлетворит клиент, ожидающий идентичность IP. Современные валидаторы в значительной степени игнорируют общее имя, поэтому дружественная метка в подробностях сертификата ничего не доказывает о том, что совпадёт. Если при устранении неполадок имя хоста заменили адресом, считайте, что ожидаемая идентичность переехала вместе с ним, пока вы не проверили. Сравнивайте строку в профиле со строкой в SAN символ за символом, потому что завершающая точка или лишний пробел уже достаточны.

Подстановочные знаки — лишь удобство DNS, и они подчиняются собственным правилам сопоставления, что является ещё одной причиной, по которой профиль на основе IP никогда не должен на них полагаться.

Найдите, где каждый клиент хранит ожидание

В strongSwan значение, сравниваемое с сертификатом, берётся из настройки идентичности партнёра: rightid в классической конфигурации или id раздела удалённого подключения в swanctl. Его документация о совместимости с Apple IKEv2 полезна здесь, потому что описывает соглашения об идентичности, которые использует клиент под управлением профиля, и эти соглашения объясняют класс несоответствий, выглядящих на линии случайными.

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

Исправляйте профиль или сертификат осознанно

Прежде чем что-либо менять, проверьте сертификат партнёра одобренными инструментами и перечислите записи SAN с их типами. Эта проверка не требует закрытого ключа и загрузки и решает вопрос за секунды. Если развёртывание предполагает одну идентичность DNS, сертификат должен содержать её как запись dNSName, а если развёртывание предполагает адрес, сертификату нужна запись iPAddress именно для этого адреса.

Если сертификат неверен, запросите у оператора исправленный с указанием конкретного ожидаемого идентификатора. Если профиль неверен, исправьте профиль и оставьте сертификат в покое. Отключение проверки идентичности убирает ошибку и убирает проверку того, что туннель говорит с нужным партнёром.

Документируйте ожидаемую идентичность для каждой клиентской платформы, потому что значение, которое один клиент выводит автоматически, на другом может потребоваться указать явно.

Дайте запросу на обновление четыре факта

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