В IKEv2 две подписи: сертификат и IKE_AUTH
CA подписывает сертификат, а партнёр подписывает свой обмен IKE_AUTH собственной схемой. Прочитайте каждую из своего поля и запишите обе.
В вашем тикете сказано, что сертификат — SHA-256, но журнал шлюза называет другой алгоритм подписи, и кто-то уже подготовил запрос на перевыпуск CA. Прежде чем этот запрос куда-либо уйдёт, разделите две подписи: одна — печать издателя на открытом ключе, другая — доказательство партнёра, что во время IKE_AUTH у него есть соответствующий закрытый ключ. Их выбирают разные компоненты, и им разрешено различаться. Чтобы прочитать каждую там, где она живёт, нужны две команды и одна таблица.
Прочитайте подпись издателя из сертификата
CA ставит свою подпись на связку между идентичностью и ключом. Эта подпись фиксирует то, что CA сделал при выпуске, а не то, что субъект сделает при подключении, поэтому её алгоритм описывает собственный выбор хэша и ключа со стороны CA. Ключ субъекта одного типа может находиться под ключом CA другого типа без всякого противоречия, а смена ключа CA — рутина, а не неисправность. Прочитайте два поля, и у вас половина описи:
openssl x509 -in peer.pem -noout -text | grep -E "Signature Algorithm|Public Key Algorithm"Запишите обе метки как отдельные пункты. Первая описывает CA, вторая описывает ключ субъекта, и ни одна из них не предсказывает онлайн-подпись.
Прочитайте онлайн-подпись из обмена IKE
Во время аутентификации каждый партнёр подписывает данные обмена своим закрытым ключом, а другая сторона проверяет это доказательство по идентичности, цепочке доверия и политике сертификата. В RSA заполнение и хэш относятся к этой онлайн-схеме, поэтому более длинный ключ или новый сертификат SHA-256 сами по себе не могут выбрать RSA-PSS для подписи аутентификации. Согласованный метод виден в журнале демона или в его списке соединений, но никогда в сертификате. Спросите каждую сторону, о чём она договорилась, потому что два направления могут различаться.
ipsec statusall | grep -i "auth\|proposal"Когда одна сторона называет схему, которую другая не может создать, вы нашли то несоответствие, о котором был тикет. Перевыпуск CA — неправильное лечение, потому что сбой был не в сертификате.
Что меняет RFC 7427, а что нет
Исходные методы нумеруются по сочетанию алгоритмов в RFC 7296. Более позднее расширение подписи RFC 7427 добавляет общий метод Digital Signature с сигнализацией поддержки хэша подписи, поэтому новый хэш больше не нуждается в собственном номере метода. Это предмет переговоров, а не предположения: партнёр не получает расширение только потому, что его библиотека умеет разбирать те же сертификаты, а партнёр, реализующий лишь исходные методы, вынуждает шлюз сохранить один из них. Это политический обмен с ценой совместимости, а не дефект.
Поддержка определяется направлением и соединением, поэтому проверяйте сборку, которая перед вами, а не полагайтесь на утверждение на уровне семейства. Матрица возможностей, написанная три года назад, описывает сборки трёхлетней давности.
Внесите в опись четыре строки
Запись, которая прекращает спор, состоит из четырёх строк, каждая прочитана в своём месте и каждая изменена своим человеком. Заполните её до любых решений, потому что именно неверная строка определяет исправление.
| Объект | Откуда читать | Кто меняет |
|---|---|---|
| подпись издателя сертификата | поле Signature Algorithm сертификата | оператор CA, при выпуске |
| открытый ключ субъекта | поле Public Key Algorithm сертификата | тот, кто создаёт ключ субъекта |
| схема аутентификации IKE | журнал демона или список соединений, уведомление auth и signature-hash | профиль IKE на обоих партнёрах |
| алгоритмы защиты IKE и ESP | список предложений соединения | профиль IPsec, по направлению |
Каждая строка несёт своё последствие для совместимости. Смена шифра ESP не выбирает подпись издателя, а ослабление проверки CA не добавляет онлайн-метод, о котором партнёры никогда не договаривались. Когда тикет заявляет о несоответствии подписи, действительно неверная строка почти никогда не первая.
Решите старый случай, не ослабляя PKI
Более старый партнёр может предлагать только схему, которую ваша политика больше не допускает. Варианты — ограниченное по времени исключение совместимости, обновление клиента или иная схема аутентификации только для этого партнёра. Перестройка PKI вокруг более слабой подписи сертификата не устраняет ограничение онлайн-обмена и ослабляет все остальные службы, доверяющие тому же CA. Запишите, какую строку вы изменили и когда исключение истекает.
Затем снова выполните оба чтения сверху, потому что изменение в одной строке может сдвинуть то, о чём договариваются в другой. Вся опись — это две команды и одна таблица, и работа одна и та же, будь партнёр маршрутизатором, ноутбуком или устройством.