Настройка mTLS пользователя

Пошагово: что нажать в админке и что прописать в вашем приложении. Что это за функция и что она вам даёт — в обзоре раздела.

Шаг 1. Отдельный удостоверяющий центр для цели

Это первый шаг, а не деталь. Пока user_mtls и wifi выписывает один и тот же промежуточный центр, ваше приложение не отличит их друг от друга: цепочка доверия у них одна и та же, clientAuth — тоже. А wifi — это сертификат машины: Alatyr выдаёт его молча, ничего не спрашивая у сотрудника. Значит он подойдёт вашему приложению вместо пользовательского, и подтверждение владельца с шага 3 перестанет что-либо значить.

Откройте Настройки → Удостоверяющие центры, найдите профиль цели user_mtls и задайте ему отдельные vault_mount и vault_role — не те, что стоят у wifi.

Результат. В списке профилей у user_mtls и wifi разные точки монтирования. Запишите имя издателя user_mtls — оно понадобится на шаге 4.

Шаг 2. Выберите, чем сотрудник подтверждает вход

Сделайте это до назначения цели: ступень применяется к ключу в момент его создания, и заявка, ушедшая раньше, уедет по прежней настройке.

Настройки → Безопасность по умолчанию — ступень подтверждения владельца для цели user_mtls:

Ступень	Что видит сотрудник
Без подтверждения	ничего не спрашивают
Биометрия или PIN устройства	отпечаток, Windows Hello, Touch ID
PIN карты	запрос PIN смарт-карты

На ступени PIN карты ключ цели переезжает на карту целиком: заявку подписывает ключ карты, сертификат выписывается на него, и собственного контейнера у цели не заводится вовсе. Это сделано намеренно — пока контейнер существует, подпись можно поставить мимо карты, и PIN не охраняет ничего.

Результат. Ступень выбрана до того, как устройство попросило сертификат.

Шаг 3. Разрешите выдачу и назначьте цель

Сертификат не появляется у сотрудника сам — выдачу разрешает администратор.

1. Откройте Настройки → Политика выдачи и включите строку «mTLS пользователя» в колонке «Выдаём». Переключатель относится только к этой цели: соседние (ssh, k8s, vpn, вход в AD) он не включает и не гасит, у каждой свой. Если включаете точечно: Устройства → раскройте строку машины → блок «Цели на этой машине» → у строки user_mtls переключите «как в системе» на «разрешить сверх системного».
2. В той же строке машины назначьте цель user_mtls.

Результат. В карточке устройства цель user_mtls числится назначенной, и через несколько минут агент подаёт заявку.

Шаг 4. Одобрите заявку

Откройте раздел Запросы. Заявка на user_mtls появится в списке — проверьте владельца и устройство и одобрите её.

Одобрение человеком обязательно

Сервисный аккаунт с ролью cert-auto-approver такую заявку одобрить не может: user_mtls — сертификат конкретного человека, и продукт требует, чтобы его выдачу подтвердил другой человек.

Результат. Сертификат выдан, агент положил его в хранилище ОС, и в карточке устройства цель числится выданной. Срок жизни — один год.

На Mac браузер предложит сертификат только при доверии корню

Для входа через браузер (в отличие от curl на шаге 6) macOS покажет сотруднику его сертификат, только если Mac доверяет корню, которым он подписан. Раздайте корень Alatyr Root CA на Mac сотрудников как доверенный — через MDM либо вручную в «Связке ключей» — или выпускайте user_mtls через свой Vault с промежуточным УЦ под вашим корпоративным корнем, если Mac и так ему доверяет. Подробнее — Пилот, шаг 5.

Сертификат не продлевается сам

За сроком следит администратор. Раздел Сертификаты показывает, когда какой истекает; поставьте себе напоминание заранее, иначе в день истечения сотрудник просто перестанет входить.

Шаг 5. Настройте ваше приложение

Вашему приложению нужны две вещи, и одна без другой не работает:

• полная цепочка — промежуточный user_mtls плюс корень в одном файле;
• проверка издателя — иначе сертификат машины пройдёт проверку цепочки целиком и попадёт в приложение.

Пример для nginx:

server {
    listen 443 ssl;
    server_name app.internal.example.com;

    ssl_certificate     /etc/nginx/tls/app.crt;
    ssl_certificate_key /etc/nginx/tls/app.key;

    # Полная цепочка: промежуточный user_mtls И корень.
    # С одним промежуточным nginx отвергает всё, включая годный сертификат.
    ssl_client_certificate /etc/nginx/tls/user-mtls-chain.pem;
    ssl_verify_client on;
    ssl_verify_depth 2;

    location / {
        # Вот что разделяет цели. Без этой строки сертификат машины
        # проходит проверку цепочки полностью и попадает в приложение.
        if ($ssl_client_i_dn != "CN=Alatyr User mTLS Issuing CA") {
            return 403;
        }
        # Личность, которую подтвердила проверка сертификата.
        proxy_set_header X-MTLS-User $ssl_client_s_dn_cn;
        proxy_pass http://app_upstream;
    }
}

Формат имени издателя

Значение сравнивается в формате RFC 2253 — CN=…, без ведущей косой черты (nginx 1.11.6 и новее). Со старым форматом /CN=… сравнение не совпадёт никогда, и отказ получат все. Сторона безопасная, но выглядит это как поломка приложения — поэтому проверяйте обе половины, шаг 6.

Готовые настройки для haproxy и OpenVPN — в «Приёмниках сертификатов».

Результат. Ваше приложение принимает сертификат user_mtls и отвечает 403 на сертификат машины.

Шаг 6. Проверьте обе половины

Проверять только законным сертификатом недостаточно: половина ошибок в настройке выглядит как «всё работает».

Половина первая — сотрудник входит. Откройте приложение на машине сотрудника. Оно должно пустить и увидеть его личность в заголовке X-MTLS-User.

Половина вторая — сертификат машины не пускают. Возьмите сертификат wifi той же машины и предъявите его тому же адресу:

curl -v --cert wifi.pem --key wifi.key https://app.internal.example.com/

Приложение должно ответить 403. Если пустило — вы либо не развели удостоверяющие центры (шаг 1), либо убрали проверку издателя (шаг 5).

Если вход не проходит

Проверяйте по порядку: сверху самые частые причины.

Приложение отвечает 400, и отказ получают все, включая сотрудника с годным сертификатом. Чаще всего в файл цепочки положили только промежуточный центр без корня. Проверка замыкается только на самоподписанном сертификате, и без корня приложение отвергает всё.

Второй частый случай — включена проверка списка отзыва, а список дали не на всю цепочку: три правила.

Отказ получают все, и в настройке есть проверка издателя. Сравните формат: значение должно быть CN=… без ведущей косой черты. Старая форма /CN=… не совпадёт никогда.

Приложение пускает сертификат машины. Удостоверяющие центры не разведены (шаг 1) либо проверка издателя убрана (шаг 5).

Сертификат не появился у сотрудника. Проверьте, назначена ли машине цель user_mtls, разрешена ли выдача (шаг 3) и одобрена ли заявка (шаг 4).

Сотрудника не спрашивают ни о чём при входе. Ступень подтверждения выбрана после того, как ключ уже создан. Ступень применяется в момент создания ключа — перевыпустите сертификат, выбрав ступень заранее (шаг 2).

Что дальше

• Отзыв доступа — забрать доступ так, чтобы вход закрылся на самом деле, а не только сменился статус в админке.
• Нюансы и пределы — чего механизм не обещает: узнать это лучше сейчас, чем на работающем приложении.
• Приёмники сертификатов — готовые настройки haproxy, nginx и OpenVPN целиком, с замерами на живых приёмниках.