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

Запишіть спостережуваний обмін, якір і отриману перевірку в запис про зміни. Виправлення сертифіката, яке не можна описати цими словами, — збіг.