mTLS: как клиент и сервер проверяют друг друга

mTLS (mutual TLS) — взаимная аутентификация в TLS: клиент проверяет сервер, а сервер — клиента по сертификатам и доказательствам владения соответствующими приватными ключами. Это возможность TLS, а не отдельный способ шифрования. В обычном HTTPS-подключении с сертификатом проверяется сервер; mTLS добавляет сертификатную проверку клиента.

Представим служебный телефон, который открывает внутренний сервис. Телефону нужно убедиться, что перед ним нужный сервер. Серверу — проверить идентичность подключившегося клиента. После этого приложение решает, можно ли ему читать отчёт или менять данные.

Три схемы и один сценарий показывают, как связаны сертификаты обеих сторон, приватные ключи, настройки доверия и права приложения. Командная строка для понимания этого механизма не требуется.

Клиент — программа, которая начинает подключение. В нашем примере это приложение на телефоне device-017. Сервер принимает соединение по адресу portal.example.org. Имена условные; это учебная ситуация, а не описание конкретного внедрения.

Сертификат — открытое удостоверение, а приватный ключ — отдельный секрет. Подпись позволяет проверить связь данных с ключом подписавшей стороны. Если эти понятия новые, начните с разбора сертификатов, ключей и подписей.

Как сертификат появляется у клиента

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

Центр сертификации проверяет запрос по правилам выдачи. Само указание имени устройства в запросе ещё не даёт права получить сертификат с этим именем. После проверки центр выпускает сертификат, связывающий открытый ключ с разрешёнными сведениями о клиенте.

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

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

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

Две стороны — два решения о доверии

Клиент принимает издателя сертификата сервера. Сервер принимает издателя клиентского сертификата. Издатели могут быть разными: знание одного корня не означает доверия другой стороны. Центр выдачи сертификатов называют CA — Certificate Authority.

Установка корневого сертификата на телефон помогает проверять чужие удостоверения. Она не выдаёт телефону собственный сертификат и не создаёт соответствующий приватный ключ. Для аутентификации клиента нужны его собственные подходящие удостоверяющие данные.

Копию сертификата можно передать. Копия не позволяет создать подпись без соответствующего приватного ключа. Контейнеры .p12 и .pfx могут содержать и сертификат, и ключ: последствия их копирования отличаются.

mTLS подтверждает владение приватным ключом, связанным с принятым сертификатом. Если доступную для использования копию этого ключа получает другой участник, он потенциально может предъявлять ту же сертификатную идентичность. Подтверждение конкретного физического устройства требует дополнительных оснований, например аппаратной защиты ключа и проверки его происхождения.

Что меняется по сравнению с обычным HTTPS

mTLS применяют там, где нужна проверяемая идентичность подключающейся программы, сервиса или устройства: например, во внутреннем API или партнёрской интеграции. Сам сертификат устройства не доказывает, какой человек сейчас держит телефон, и не подтверждает состояние его программ.

Обязательный и необязательный клиентский сертификат

Сервер должен запросить клиентский сертификат и применить нужную политику. Запросить сертификат и запретить соединение без него — разные настройки. Для нашего сценария выбран второй вариант: отсутствие клиентского удостоверения приводит к отказу.

Например, в NGINX есть разные режимы проверки клиента. Их смысл описан в документации NGINX ↗. Это иллюстрация различия режимов, а не готовая конфигурация для копирования.

Что подтверждает каждая сторона

1. Сервер запрашивает сертификат клиента и предъявляет свой. Телефон получает удостоверение сервиса и доказательство владения серверным ключом.
2. Телефон проверяет сервер. Проверяет имя сервиса, путь к принятому издателю, срок и применимые ограничения; затем проверяет подпись данных текущего установления соединения.
3. Телефон предъявляет своё удостоверение и доказательство. Для нового сертификатного соединения TLS 1.3 он подписывает данные рукопожатия своим приватным ключом. Сам ключ не отправляет.
4. Сервер проверяет клиента. Проверяет его сертификат по своим правилам и подпись соответствующим открытым ключом. При успешном завершении соединения приложение получает основание работать с установленной идентичностью.

Рукопожатие — начальное согласование параметров соединения. Подпись издателя внутри сертификата и подпись участника в текущем рукопожатии выполняют разные задачи: первая удостоверяет сведения, вторая подтверждает владение ключом именно при этом подключении.

На схеме ниже показан фрагмент аутентификации нового TLS 1.3 соединения. Согласование ключей и служебные сообщения опущены; порядок проверки нельзя переносить на все варианты возобновления сеансов. Протокол описан в RFC 9846 — TLS 1.3 ↗.

Идентичность клиента и разрешённые действия

Сертификат device-017 прошёл проверку. Сервис сопоставляет согласованные сведения сертификата с записью клиента и разрешает чтение отчёта. Другому клиенту device-018 тот же издатель выдал действительный сертификат, но прав на отчёт у него нет. Его TLS-подключение может пройти, а запрос получить отказ приложения.

Сопоставление — отдельное правило системы: какое удостоверенное значение обозначает клиента и какие действия с ним связаны. Нельзя автоматически считать любое поле имени уникальной учётной записью или давать одинаковые права всем сертификатам принятого CA. Для HTTPS имя сервера проверяют по предусмотренным для этого именам в сертификате; идентичность клиента требует собственного соглашения.

mTLS может работать вместе со входом пользователя, токенами и ролями. Устройство, приложение и пользователь — разные участники модели. Подробнее о правилах операций — в проверке безопасности API.

Если TLS завершается на прокси

Прокси или балансировщик — посредник, который может принимать TLS-соединение вместо приложения. Тогда телефон проверяет его сертификат, а он проверяет телефон. Участок от посредника до приложения — другое соединение, со своей защитой и возможной аутентификацией.

Переданные приложению сведения сертификата не становятся новым доказательством владения клиентским ключом. Если они поступают через HTTP-заголовки, нужно обеспечить доверенный путь от посредника, запретить обход и исключить подмену таких заголовков внешним клиентом. Возможность передачи сведений показана в документации Yandex Cloud ↗. В нашем основном примере TLS завершается непосредственно на сервере.

Какие настройки определяют взаимную проверку

Результат зависит от точки завершения TLS, правил выдачи и использования сертификатов, доверия обеих сторон и сопоставления клиентской идентичности с правами приложения.

В таблице показаны роли участников; их распределение зависит от устройства конкретной системы. Выпуск, доставка, настройка использования и аутентификация клиента происходят на разных этапах.

Результаты подключения и причины отказа

В учебном примере новое подключение клиента device-017 проходит обе проверки, после чего приложение разрешает чтение отчёта. Другие условия дают разные результаты:

• Без клиентского сертификата и с сертификатом непринятого издателя сервер отклоняет соединение.
• При неподходящем имени сервера или недоверенном серверном издателе соединение отклоняет клиент.
• Истёкший клиентский сертификат и сертификат с неподходящим назначением не принимаются.
• Скопированный сертификат без соответствующего ключа не позволяет выполнить нужное доказательство.
• Подходящий клиентский сертификат без прав на отчёт проходит TLS, но операция запрещена приложением.

Этот механизм воспроизведён на новом TLS 1.3 соединении в изолированном учебном стенде с Python 3.12 и OpenSSL 3.0.13. Использованы разные центры для сертификатов сервера и клиентов. Во втором клиентском сценарии TLS прошёл, а приложение вернуло HTTP 403. Несоответствующий ключ был обнаружен ещё при загрузке пары сертификат–ключ. Это учебная проверка, не результат внедрения у заказчика.

На какой стороне возникает отказ

Сторона, отклонившая соединение, определяет набор применённых правил. Одинаковая фраза «сертификат не принят» не означает одинаковую причину. Ошибка доверия связана с издателем и настройками проверяющей стороны; ошибка имени — с адресом сервера; отсутствие клиентского сертификата — с его доступностью и выбором приложением, а также требованиями сервера.

HTTP 403 сам по себе не доказывает успешную взаимную аутентификацию: некоторые шлюзы возвращают HTTP-ошибку по собственной политике. Журнал точки TLS, результат проверки сертификата и идентичность, переданная приложению, позволяют различить эти ситуации. Устройство может хранить несколько сертификатов; установка файла не гарантирует выбор нужного.

Идентичность, доверие и доступ

Успешная взаимная аутентификация означает, что обе стороны приняли сертификаты и доказательства владения ключами по своим правилам. Этот результат относится к определённым клиенту, точке TLS и настройкам проверки.

В нашем примере телефон device-017 подключается к portal.example.org и читает отчёт. Без принятого клиентского сертификата соединение отклоняется. Клиент device-018 с подходящим сертификатом проходит TLS, но не получает права читать отчёт: это решение приложения.

Приватные ключи не входят в диагностическое описание подключения. Сведения сертификатов могут раскрывать внутренние имена. Эффект отзыва и замены зависит от политики проверки и поведения уже установленных сеансов. Успешный TLS в этом примере не доказывает проверку отзыва или состояние устройства.

Частые вопросы о mTLS

1. На телефон установили корневой сертификат. Теперь сервер узнает телефон? Нет. Настроено доверие к чужому удостоверению; для предъявления своей идентичности нужны собственный сертификат и владение ключом.
2. Клиент доверяет серверу. Сервер обязан доверять клиенту? Нет. Это разные решения проверяющих сторон.
3. Сертификат телефона скопировали. Получится повторить вход? Одного сертификата недостаточно; копирование контейнера с приватным ключом меняет ситуацию.
4. Сервер запросил сертификат, но принял соединение без него. Обязательная проверка настроена? Принятие соединения без сертификата означает, что его обязательное предъявление не обеспечено в этом сценарии.
5. Сертификат действительный, но операция запрещена. Противоречие? Нет. Удостоверение клиента и разрешение операции отвечают на разные вопросы.
6. Телефон прошёл mTLS на балансировщике. Приложение тоже напрямую проверило его ключ? Сертификат клиента и доказательство владения его ключом проверил балансировщик. Приложение получает сведения об идентичности через отдельно настроенное взаимодействие с ним.

Удаление записи из каталога, удаление сертификата с устройства и отзыв меняют разные состояния. Ни одно из этих действий автоматически не описывает последствия для всех копий сертификата, ключа и уже установленных соединений.

Куда перейти дальше

Если отказ связан с издателем, промежуточным сертификатом или доверенным корнем, механизм объясняет разбор цепочки сертификатов.