Помилка довіри Android IKEv2: надішліть проміжний CA, а не кореневий
Телефон відхиляє шлюз, бо отриманий ланцюжок обривається зарано. Вирішіть: надіслати проміжний, виправити ідентичність або змінити тип ключа.
Телефон відмовляється підключатися й виводить No trusted RSA public key found for vpn.example.net, хоча той самий сертифікат шлюзу працює з ноутбука в тій самій мережі. Спокусливий крок — перевипустити сертифікат. Перш ніж це робити, з'ясуйте, яка з трьох несправностей у вас, бо лише одна з них стосується вмісту сертифіката. Повідомлення охоплює неповний ланцюжок, незбіг ідентичності та непідтримуваний ключ або підпис, і кожна має інше виправлення.
Три несправності за одним повідомленням
Android будує ланцюжок від сертифіката шлюзу до CA, вибраного в профілі VPN, потім порівнює ім'я сервера з профілем. Сповіщення повідомляє результат, а не етап. Несправність довіри означає, що ланцюжок не вдалося завершити з сертифікатів, переданих в обміні; несправність ідентичності означає, що ланцюжок перевірено, але ім'я не збіглося; несправність алгоритму означає, що пристрій або профіль не приймає тип ключа чи підпис.
| What you see | What it points to | First move |
|---|---|---|
| Chain stops after the leaf in the daemon log | intermediate not loaded or not sent | load the intermediate as CA material |
| Chain validates, name differs from the profile | identity mismatch | fix the profile name or the certificate SAN |
| Chain validates, handshake still fails | key or signature not accepted | compare key type against the device |
Вирішуйте за доказами, а не перебираючи виправлення по черзі. Одна спроба на рівні журналу 2 проти демона скаже, у якому ви рядку, і коштує менше, ніж перевипуск сертифіката, який ніколи не був неправильним.
Спершу вирішіть: чи надійшов увесь ланцюжок?
strongSwan надсилає сертифікат, налаштований для цього з'єднання, а проміжні сертифікати — окремі облікові дані. Їх треба завантажити як сертифікати CA, перш ніж демон зможе розмістити їх у корисному навантаженні, тому схема, де сертифікат сервера підписано проміжним, корінь є якорем довіри, а проміжний лежить лише в каталозі збирання CA, дає саме цю несправність: на дроті лише листок, ланцюжок рано закінчується на телефоні.
Перевірте, що має демон, за допомогою swanctl --list-certs у розгортанні swanctl або ipsec listcerts зі старішим starter. Проміжний має з'явитися як сертифікат CA з коренем над ним. Якщо його немає, жодна клієнтська опція не допоможе; якщо він є, переходьте до наступного питання.
Потім перевірте, чи його буде надіслано. Довідка swanctl.conf описує send_cert, чиє типове значення ifasked надсилає сертифікати лише коли партнер попросив; always надсилає завжди. Застарілий відповідник — leftsendcert=always у ipsec.conf. Це налаштування керує надсиланням, а не доступністю, тому не може компенсувати проміжний, який демон так і не завантажив.
Якщо ланцюжок короткий, завантажте проміжний туди, де шукає демон
Покладіть проміжний у каталог CA, а не поруч із листком: /etc/ipsec.d/cacerts для конфігурації ipsec.conf, /etc/swanctl/x509ca для swanctl або шлях, який підставляє ваш пакет. Перезавантажте конфігурацію й знову перелічіть сертифікати. Деякі версії також надсилають пакет, що містить ланцюжок у файлі листка, але каталог CA — переносне рішення для різних версій і пакетів.
Перевірте й з боку клієнта. Телефон бачить лише те, що переніс обмін, тому журнал демона на рівні 2 має показувати проміжний серед переданих сертифікатів. Якщо журнал його показує, а телефон усе одно не підключається, ви в іншому рядку таблиці, і подальше коригування файлів CA не змінить результату.
Якщо ланцюжок повний, припиніть редагувати сертифікати
Несправність ідентичності — це незбіг імені в профілі VPN та імені в сертифікаті. Android порівнює налаштовану вами ідентичність сервера із сертифікатом, який він перевірив, тому профіль, що вказує на адресу, тоді як сертифікат називає ім'я хоста, або профіль з іменем хоста, якого сертифікат не покриває, зазнає невдачі після успішної перевірки ланцюжка. Виправте неправильний бік і тримайте профіль та сертифікат узгодженими, коли будь-який із них змінюється.
Несправність алгоритму виявляється з чинним ланцюжком і відповідним іменем. Версії Android різняться тим, які типи ключів і схеми підпису вони приймають, і сам тип профілю обмежує варіанти. Якщо шлюз використовує старішу або незвичну комбінацію, порівняйте її з тим, що підтримує пристрій, перш ніж вважати сертифікат пошкодженим. Журнал демона покаже, що рукостискання просувається далі, ніж у випадку довіри, і це сигнал, що ланцюжок більше не проблема.
Не встановлюйте проміжний як користувацький корінь на телефоні
Встановлення відсутнього проміжного як користувацького сертифіката на телефоні прибирає попередження й змінює модель довіри телефона для кожного застосунку, що приймає встановлені користувачем корені. Це також приховує помилку доставлення, яка вдарить по наступному клієнту, і залишає шлюз надсилати неповний ланцюжок кожному майбутньому пристрою. Надійне виправлення — на сервері, один раз, для всіх клієнтів.
Тримайте три рішення окремо в записі змін: які сертифікати передано, яку ідентичність порівняно і який алгоритм узгоджено. Шлюз, що завжди надсилає повний ланцюжок, профіль, що правильно називає сертифікат, і тип ключа, який підтримує парк, — це три маленькі факти, і вони становлять усю цю несправність.