AWS Client VPN: сертифікат сервера і роль клієнтського сертифіката

Кінцевій точці Client VPN завжди потрібен TLS-сертифікат сервера. Це та ідентичність, яку керована кінцева точка пред'являє під час підключення клієнта. Це інший об'єкт, ніж сертифікати, які пред'являють окремі клієнти за взаємної автентифікації. Плутати їх — найчастіша причина, чому інакше правильне налаштування ACM усе одно зривається на першому ж підключенні.

Нижче — прохід від консолі назовні, у тому порядку, яким з'єднання справді йде.

Дві ролі, одна кінцева точка

Кінцева точка має ідентичність сервера і, за бажанням, спосіб перевірки ідентичностей клієнтів. Вони налаштовуються окремо. Одна сторона вирішує, чи може клієнт довіряти службі; інша вирішує, чи приймає служба клієнта.

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

Що робить сертифікат сервера в ACM

Під час створення кінцевої точки сертифікат сервера має бути доступним в ACM у тому самому регіоні, що й кінцева точка. Консоль запитує ARN, і цей ARN має там розв'язуватися. ACM може зберігати сертифікат, виданий із перевіркою домену, або той, який ви імпортували разом із ключем і ланцюжком. Обидва працюють у цій ролі; вони різняться поновленням і тим, у кого закритий ключ.

Обирайте шлях отримання за тим, хто може поновити сертифікат, а не за тим, який випадково дав файл, що виглядає правильним.

Що додає взаємна автентифікація

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

Метод автентифікації кінцевої точки — це вибір, а не загальна вимога.

Active Directory і федеративна автентифікація відповідають на те саме питання іншими засобами. Рецепт із взаємними сертифікатами не стає автоматично схемою входу для таких розгортань, і перевірка TLS на сервері зберігається незалежно від того, як користувача допускають усередину.

Чому той самий ARN CA — не обмін ключами

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

Коли CA клієнта — інший видавець, документований шлях полягає в тому, щоб імпортувати цей CA в ACM і вибрати його для ролі клієнта.

Поверніть збій до етапу

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

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

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

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