strongSwan send_cert: когда отправляется сертификат IKE

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

Что на самом деле управляет send_cert

Аутентификация по сертификату требует, чтобы сертификат конечного объекта другой стороны дошёл до неё через обмен IKE или через предварительную подготовку. В swanctl параметр соединения send_cert определяет, включает ли эта конечная точка полезную нагрузку своего сертификата: никогда, всегда или ifasked. Значение по умолчанию ifasked отправляет его в ответ на запрос сертификата от peer. Запрос сертификата — отдельный параметр, потому что просить другую сторону о её сертификате не то же самое, что предлагать свой.

Более старые развёртывания ipsec.conf использовали leftsendcert и rightsendcert, и эти имена соответствуют локальной и удалённой ролям, а не напрямую swanctl.

Прочитайте одну попытку, прежде чем менять соединение

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

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan --since "10 min ago" | grep -iE "cert|CERT"

Список соединений показывает заданное значение send_cert, а список SA показывает, какие соединения действительно поднялись. Журнал добавляет подробности согласования: был ли получен запрос сертификата и ушла ли полезная нагрузка сертификата. Общая ошибка аутентификации не указывает на проблему доставки, поэтому найдите конкретный обмен, прежде чем делать выводы. Запишите отметку времени попытки, чтобы окно журнала покрывало всё рукопожатие.

Доверие получателя — отдельное решение

Доставка и доверие — разные свойства, и исправление одного не исправляет другое. Получатель должен располагать нужным якорем доверия, получить пригодную цепочку и совпасть с ожидаемой идентичностью peer. Сертификат конечного объекта, пришедший без своего промежуточного сертификата, всё равно не проходит строгую проверку цепочки. И наоборот, установка CA вовсе не заставляет peer отправлять свой сертификат.

openssl x509 -in peer-chain.pem -noout -subject -issuer -dates

Проверка показывает, какой издатель подписал сертификат и когда он истекает, и именно этому должен соответствовать якорь получателя. Доверяйте выпускающему CA, которым владеет развёртывание, а не каждому промежуточному сертификату в цепочке, потому что повышение каждого промежуточного до корневого расширяет доверие далеко за пределы одного peer. Оставляйте проверку идентичности включённой, потому что соединение, которое проходит только при отключённой проверке, — не исправление. Там, где цепочка неполна, исправляйте подготовку, а не политику отправителя.

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

Когда журнал показывает, что сертификат не отправлялся, а получатель его действительно запрашивал, значение send_cert always — обоснованное изменение для этого соединения. Примените его в конфигурации swanctl, перезагрузите соединения и установите новый сеанс вместо повторного использования существующего SA. Подтвердите, что полезная нагрузка сертификата теперь появляется и что получатель принимает её относительно нужного якоря. Если ничего не меняется, значит, ошибка была на стороне доверия и настройка отправителя ни при чём.

Запишите наблюдавшуюся передачу, якорь и полученную проверку в запись об изменениях. Исправление сертификата, которое нельзя описать этими словами, — совпадение.