В обычном HTTPS только сервер подтверждает свою личность с помощью сертификата. Клиент (браузер) остаётся анонимным — сервер не знает, кто подключается.
Mutual TLS (mTLS) добавляет второй шаг: клиент тоже предъявляет сертификат. Обе стороны аутентифицируют друг друга. Сервер проверяет сертификат клиента по доверенному удостоверяющему центру (CA), а клиент проверяет сертификат сервера — отсюда название «взаимный» (mutual).
Обычный TLS vs Mutual TLS
| Обычный TLS | Mutual TLS (mTLS) | |
|---|---|---|
| Сервер подтверждает личность | ✅ Сертификат + подпись CA | ✅ То же самое |
| Клиент подтверждает личность | ❌ Анонимный | ✅ Клиентский сертификат |
| Аутентификация | Односторонняя (только сервер) | Двусторонняя (оба) |
| Сценарий использования | Публичные веб-сайты | Внутренние API, zero trust |
| Клиенту требуется | Только браузер | Сертификат + закрытый ключ |
| Сложность настройки | Стандартная | Выше — нужно управлять клиентскими сертификатами |
Когда использовать mTLS
Коммуникация между сервисами
Микросервисы, взаимодействующие друг с другом по сети. mTLS гарантирует, что подключаться могут только авторизованные сервисы — а не любой, кто знает URL.
Service A ←──mTLS──→ Service B
Оба проверяют: «Ты тот, за кого себя выдаёшь?»Архитектура Zero Trust
В Zero Trust ни одно сетевое соединение не является доверенным по умолчанию — даже внутри корпоративной сети. mTLS заменяет доверие на сетевом уровне (файрволы, VPN) на доверие на уровне идентификации (сертификаты).
Безопасность API
Защита конфиденциальных API за пределами простых API-ключей. Украденный API-ключ может использовать кто угодно. Клиентский сертификат привязан к конкретному закрытому ключу — его сложнее украсть и использовать.
Аутентификация IoT-устройств
Устройства подключаются к серверу с клиентскими сертификатами, установленными в процессе производства. Сервер знает, что взаимодействует с подлинным устройством, а не с поддельным.
Как работает mTLS
- Клиент подключается и инициирует TLS-рукопожатие (так же, как в обычном TLS)
- Сервер отправляет свой сертификат — клиент его проверяет (так же, как в обычном TLS)
- Сервер запрашивает клиентский сертификат — отправляет сообщение
CertificateRequest - Клиент отправляет свой сертификат — сервер проверяет его по доверенному CA
- Обе стороны вычисляют сеансовые ключи и начинается зашифрованная связь
Шаги 3-4 — это то, что делает процесс «взаимным».
Конфигурация mTLS в Nginx
server {
listen 443 ssl;
server_name api.example.com;
# Сертификат сервера (так же, как в обычном HTTPS)
ssl_certificate /etc/ssl/server-fullchain.pem;
ssl_certificate_key /etc/ssl/server-privkey.pem;
# Проверка клиентского сертификата
ssl_client_certificate /etc/ssl/client-ca.pem; # CA, подписавший клиентские сертификаты
ssl_verify_client on; # Требовать клиентский сертификат
# Опционально: передать информацию о клиентском сертификате в приложение
proxy_set_header X-Client-DN $ssl_client_s_dn;
proxy_set_header X-Client-Verify $ssl_client_verify;
}mTLS vs другие методы аутентификации
| Метод | Уровень безопасности | Сложность | Лучше всего для |
|---|---|---|---|
| API-ключ | Низкий (можно передать) | Низкая | Публичные API, ограничение частоты запросов |
| OAuth/JWT | Средний | Средняя | API для пользователей |
| mTLS | Высокий (криптографически привязан) | Высокая | Взаимодействие сервисов, zero trust |
| mTLS + JWT | Наивысший | Высокая | Аутентификация на транспортном и прикладном уровне |
mTLS и GetHTTPS
GetHTTPS выпускает серверные сертификаты — сертификаты, которые ваш веб-сервер использует для подтверждения своей личности. Это стандартные SSL-сертификаты, используемые каждым HTTPS-сайтом.
Клиентские сертификаты для mTLS обычно выпускаются частным CA (внутренним удостоверяющим центром вашей организации), а не публичным CA вроде Let’s Encrypt. Let’s Encrypt не выпускает клиентские сертификаты — он выпускает только серверные сертификаты для публичных доменов.
Часто задаваемые вопросы
Можно ли использовать Let’s Encrypt для mTLS?
Для серверного сертификата: да. Для клиентских сертификатов: нет. Клиентские сертификаты должны выпускаться частным CA, которым вы управляете — чтобы вы решали, какие клиенты авторизованы. Инструменты вроде openssl, cfssl или step-ca могут выступать в роли вашего частного CA.
mTLS — это то же самое, что «аутентификация по клиентскому сертификату»?
Да. «Mutual TLS», «mTLS», «двусторонний TLS» и «аутентификация по клиентскому сертификату» — всё это относится к одному и тому же — обе стороны предъявляют сертификаты во время TLS-рукопожатия.
mTLS заменяет API-ключи?
Может, но они служат разным целям. mTLS подтверждает идентификацию на транспортном уровне (какой сервис подключается). API-ключи/JWT подтверждают идентификацию на прикладном уровне (какой пользователь/разрешение). Многие системы используют оба подхода вместе для эшелонированной защиты.
Где mTLS обычно используется?
Kubernetes (service mesh с Istio/Linkerd), Cloudflare Access, AWS API Gateway (mutual TLS), Google Cloud BeyondCorp и большинство корпоративных реализаций zero-trust.