SAN сертифіката IKEv2: чому перевірка ідентичності не проходить
Дійсний сертифікат IKEv2 усе одно не проходить, якщо очікувана ідентичність і тип SAN не збігаються. Зіставте DNS з DNS, IP з IP і спершу перевірте профіль.
Ваш сертифікат вибудований у ланцюжок до довіреного CA, дати гаразд, а партнер усе одно відмовляється завершити фазу 1 з помилкою ідентичності. Доступність і дійсний підпис — лише половина того, що перевіряє клієнт IKEv2. Друга половина — чи присутня очікувана ідентичність у сертифікаті в потрібному полі, і це очікування задає профіль, а не ім'я файлу сертифіката.
Симптом завжди однакової форми
Профіль з'єднання змінюють з імені хоста на IP-адресу або оновлюють із сертифіката, що містив DNS-ім'я, на сертифікат, що містить лише адреси, ітунель перестає узгоджуватися. У мережевому шляху нічого не змінилося. Клієнт досягає партнера, отримує сертифікат і відхиляє ідентичність партнера, бо ідентифікатор, який йому веліли очікувати, не поданий у полі, яке він приймає. Оновлення — звичайний тригер, адже замінювальний сертифікат часто походить з іншого шаблону, ніж замінюваний.
Потім обидві сторони записують щось марне, тому збій зазвичай реєструють як проблему із сертифікатом. У журналі клієнта може бути названа потрібна ідентичність, і це ім'я — потрібна вам підказка, а не дата завершення.
Зіставляйте тип ідентифікатора, а не лише значення
SAN типу dNSName і SAN типу iPAddress — різні поля з різними правилами зіставлення, тому сертифікат із 203.0.113.10 як рядком DNS не задовольнить клієнт, що очікує ідентичність IP. Сучасні валідатори здебільшого ігнорують загальне ім'я, тому дружня мітка в подробицях сертифіката нічого не доводить про те, що збіжиться. Якщо під час усунення несправностей ім'я хоста замінили адресою, вважайте, що очікувана ідентичність переїхала разом із ним, доки ви не перевірили. Порівнюйте рядок у профілі з рядком у SAN символ за символом, бо завершальна крапка або зайвий пробіл уже достатні.
Підстановні символи — лише зручність DNS, і вони підкоряються власним правилам зіставлення, що є ще однією причиною, чому профіль на основі IP ніколи не повинен на них покладатися.
Знайдіть, де кожен клієнт зберігає очікування
У strongSwan значення, яке порівнюють із сертифікатом, походить із налаштування ідентичності партнера: rightid у класичній конфігурації або id розділу віддаленого з'єднання в swanctl. Його документація про сумісність з Apple IKEv2 корисна тут, бо описує конвенції ідентичності, які використовує клієнт під керуванням профілю, і ці конвенції пояснюють клас невідповідностей, що на лінії виглядають випадковими.
Профілі конфігурації Apple містять поле віддаленого ідентифікатора, і саме це значення перевіряє клієнт, а не адресу сервера в налаштуваннях з'єднання. Клієнти Windows і пристроїв мають кожен своє поле зі своїм значенням за замовчуванням, і значення за замовчуванням часто прямує за введеною вами адресою. Коли два поля розходяться, перемагає те, яке клієнт справді читає, і це рідко те, яке ви редагували.
Виправляйте профіль або сертифікат свідомо
Перш ніж щось змінювати, перевірте сертифікат партнера схваленими інструментами та перелічіть записи SAN з їхніми типами. Ця перевірка не потребує закритого ключа й завантаження і вирішує питання за секунди. Якщо розгортання передбачає одну ідентичність DNS, сертифікат має містити її як запис dNSName, а якщо розгортання передбачає адресу, сертифікату потрібен запис iPAddress саме для цієї адреси.
Якщо сертифікат неправильний, попросіть в оператора виправлений із зазначенням конкретного очікуваного ідентифікатора. Якщо профіль неправильний, виправте профіль і залиште сертифікат у спокої. Вимкнення перевірки ідентичності прибирає помилку й прибирає перевірку того, що тунель говорить із потрібним партнером.
Документуйте очікувану ідентичність для кожної клієнтської платформи, бо значення, яке один клієнт виводить автоматично, на іншому може потребувати явного зазначення.
Дайте запиту на оновлення чотири факти
Запишіть очікуваний ідентифікатор і його тип, записи SAN, які поточний сертифікат справді має, клієнт і версію, що виконують перевірку, і точний текст помилки. Запит на оновлення, складений із цих чотирьох рядків, з першого разу отримує правильний сертифікат, а не ще один із тим самим знайомим іменем файлу.