Невідповідність сертифіката SSTP: ім'я, яке має пред'явити ваш сервер

Клієнт порівнює ім'я хоста з профілю із сертифікатом, потім перевіряє ланцюжок і призначення. Виправте профіль або сертифікат, але ніколи не перевірку.

SSTP клієнт приймає сервер лише після успішної перевірки TLS, і ця перевірка порівнює ім'я, ланцюжок і призначення. Ім'я береться з профілю з'єднання, а не з адреси, яку вам випадково вдається пінгнути. Коли одне з трьох не збігається, клієнт повідомляє про проблему із сертифікатом і ніколи не доходить до запрошення на вхід.

Ім'я в профілі визначає, що перевіряється

SSTP запускає TLS поверх TCP 443, тому клієнт поводиться як будь-який інший TLS-клієнт: бере ім'я хоста з профілю, запитує це ім'я і порівнює з ним сертифікат. Якщо вписати в профіль IP-адресу, порівняння стане порівнянням IP-адрес, якому більшість серверних сертифікатів не відповідає.

Тому тест у браузері може пройти, а VPN — ні: браузер використав інше ім'я, не те, що в профілі. Те саме розходження виникає, коли split-horizon DNS розв'язує ім'я хоста VPN у внутрішню адресу, а браузер потрапив на публічну. Спершу узгодьте профіль із задокументованим ім'ям хоста, а вже потім порівнюйте сертифікати. Усе інше, що ви зміните до цього, — здогад.

Що має містити сертифікат сервера

Сучасні клієнти звіряються з розширенням альтернативних імен суб'єкта, тому ім'я хоста має бути там як запис DNS. Лише загальне ім'я не достатньо для нинішніх стеків перевірки, а підстановочний знак покриває одну мітку, а не будь-який вигаданий вами піддомен. Три сертифікати показують межу: правильне ім'я з неправильним призначенням підтверджує особу і потім не проходить перевірку призначення, правильні ім'я та призначення з відсутнім проміжним сертифікатом не проходять ланцюжок, а ім'я, яке є лише в загальному імені, не проходить раніше, ніж щось із цих двох стане важливим.

Сертифікату потрібне й призначення автентифікації сервера — значення розширеного використання ключа, назване в специфікації Microsoft щодо SSTP, тобто serverAuth з ідентифікатором об'єкта 1.3.6.1.5.5.7.3.1. Використання ключа та дійсний ланцюжок завершують набір. Сертифікат, який є на сервері, виданий на правильне ім'я, але лише для автентифікації клієнта, усе одно не проходить.

Перевірте ланцюжок і годинник до облікових даних

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

# from the client, or any host that runs openssl
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | openssl x509 -noout -subject -dates -ext subjectAltName
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -verify_return_error </dev/null
# on the Windows server that holds the SSTP listener
w32tm /query /status

Перша команда друкує ім'я, період дії та альтернативні імена, з якими клієнт буде порівнювати. Друга повідомляє про помилки перевірки разом із поданим ланцюжком, і саме там з'являється відсутній проміжний сертифікат. У Windows запит до служби часу скаже, чи годинник коригується, чи просто відійшов.

Внутрішній CA додає ще одну умову: клієнт має довіряти цьому CA. Установіть корінь організації через схвалений канал розповсюдження, а не зі сторінки, що пропонує заміну сертифіката, бо це рішення і є вся модель довіри в мініатюрі.

Перевірка сервера й автентифікація користувача — послідовні етапи з різними збоями. Помилка сертифіката означає, що клієнт так і не довірився серверу, а відхилений пароль означає, що довірився, але дані були неправильні. Вимкнення перевірки сертифіката, щоб дістатися до запиту пароля, прибирає гарантію замість того, щоб її виправити. Щоб довести, що решта шляху працює, перевірте те саме ім'я хоста й порт із клієнта, який уже довіряє ланцюжку, і не чіпайте розгорнутий профіль.

Виправте ім'я або сертифікат і повторіть тест

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

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

Схожі статті