strongSwan: тип ключа, завантажувач і неправильний backend

PEM — це контейнер, а не тип ключа. Порівняйте відкритий ключ сертифіката із закритим, а потім завантажте його через backend, який справді його читає.

Розширення файлів не визначають алгоритми ключів, і оболонка .pem може містити матеріал RSA або ECDSA. PEM описує, як упаковано байти, тоді як RSA і ECDSA позначають різні алгоритми, а файл PKCS12 — це ще третє. strongSwan завантажує облікові дані через плагіни та конфігураційний backend, тому сертифікат може з’явитися в списку, а закритий ключ так і не стане придатним до використання. Розділіть ці рівні, перш ніж правити будь-який секрет.

Кодування, алгоритм і пакування — три рівні

Файл ключа має кодування, алгоритм і часто контейнер. PEM — знайома оболонка base64; DER — її двійковий відповідник; PKCS12 об’єднує сертифікат із його ключем і ланцюжком. Файл ланцюжка сертифікатів — ще один контейнер, і зазвичай він зовсім не містить закритого ключа. Жодна з цих позначок не каже, чи всередині RSA або ECDSA.

Читайте алгоритм із самого об’єкта. Маркетингова назва постачальника або розширення файлу не є доказом, адже той самий видавець може випускати різні типи ключів.

Порівняйте відкриті ключі, перш ніж звинувачувати завантажувач

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

openssl x509 -in server.crt -pubkey -noout |
    openssl pkey -pubin -outform DER |
    openssl dgst -sha256

openssl pkey -in server-key.pem -pubout -outform DER |
    openssl dgst -sha256

Друга команда торкається закритого матеріалу на вашій машині, але виводить лише відкриту половину. Залиште так і ніколи не вставляйте закритий ключ у тикет. Якщо ключ зашифровано, дозвольте підтримуваному інструменту запитати пароль, а не класти його в командний рядок, де список процесів може його розкрити.

Старі ipsec.secrets або облікові дані swanctl

У strongSwan є два поширені шляхи облікових даних. Старий стек starter читає записи, специфічні для типу, з ipsec.secrets, і кожен запис має вказувати правильний тип для матеріалу. Стек swanctl і vici завантажує ключі з власного каталогу облікових даних через власну конфігурацію. Правка файлу, який працюючий backend не читає, нічого не змінює.

: ECDSA "/etc/ipsec.d/private/server-key.pem"

З’ясуйте, який backend насправді працює, а потім покладіть ключ туди, куди дивиться цей backend. старий посібник strongSwan 5.9 визначає записи секретів, специфічні для типу, і це не документація swanctl. Змішування обох породжує демон, який ігнорує файл, що його адміністратор вважає авторитетним. Перезавантаження, яке не повідомляє про помилку, означає лише те, що конфігурацію розібрано.

Читайте подію завантаження та результат автентифікації

Після контрольованого перезавантаження прочитайте власний вивід завантаження демона для конкретного ключа. Сертифікат, указаний у дампі стану, не показує, що закритий ключ було зіставлено з ним.

Якщо клієнт досі зазнає невдачі, тримайте подію сервера та помилку клієнта окремо. Перевірка ланцюжка, зіставлення ідентичності та сумісність методів — це подальші питання з власними доказами. Запишіть результат із точним шляхом ключа та хешем, який ви порівняли, бо інакше наступна зміна повторить те саме перезавантаження. Заміна CA — не перша реакція на невідповідність завантажувача.

Схожі статті