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 выпустил клиентский сертификат и какой метод аутентификации конечная точка использует на самом деле. Три строки записи превращают очередное продление в задачу, а не в расследование.