У 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. Запишіть, який рядок ви змінили і коли виняток спливає.
Потім знову виконайте обидва читання згори, бо зміна в одному рядку може зсунути те, про що домовляються в іншому. Увесь перелік — це дві команди й одна таблиця, і робота та сама, чи партнер є маршрутизатором, ноутбуком або пристроєм.