Сервер отправляет CertificateRequest с допустимыми алгоритмами подписи и, при необходимости, именами CA; клиент отвечает своей цепочкой и подписью над транскриптом. Сервер проверяет цепочку по собственному хранилищу доверенных сертификатов (обычно это частный CA) и сопоставляет сертификат с удостоверением, например с SPIFFE ID в URI из SAN или с именем субъекта.
На mTLS опираются сервисные сетки (service mesh: Istio, Linkerd), шлюзы с моделью нулевого доверия (zero trust), платёжные сети, парки IoT-устройств, а также аутентификация клиентов OAuth 2.0 по mTLS и токены с привязкой к сертификату (RFC 8705). Привязка к сертификату сохраняется только при сквозном соединении: прокси, на котором завершается TLS, должен передавать проверенное удостоверение клиента в доверенном заголовке.
Публичные TLS-сертификаты больше не служат источником клиентских сертификатов: корневая программа Chrome требует EKU только для аутентификации серверов, а публичные CA в 2026 году перестали включать clientAuth в TLS-сертификаты. Используйте частный CA с краткосрочными сертификатами.