Ответ
Оба типа сертификатов используются для аутентификации в рамках TLS, но играют противоположные роли. Я настраивал их для защиты внутренних API и админ-панелей.
-
Серверный сертификат используется для аутентификации сервера перед клиентом. Это основа HTTPS. Когда вы заходите на
https://example.com, ваш браузер проверяет сертификат сервера, чтобы убедиться, что он легитимный и принадлежит именноexample.com. Он содержит доменное имя сервера (Common Name или Subject Alternative Name) и подписан доверенным центром сертификации (CA). -
Клиентский сертификат используется для аутентификации клиента (пользователя или устройства) перед сервером. Это форма взаимной аутентификации (mTLS). Сервер не только предъявляет свой сертификат, но и требует, чтобы клиент предъявил свой, выданный доверенным CA. Это гораздо более строгий метод, чем логин/пароль или токен.
Практический пример настройки mTLS для Nginx (доступ к панели управления):
server {
listen 443 ssl;
server_name admin.internal.company.com;
# 1. Серверный сертификат (для HTTPS)
ssl_certificate /etc/ssl/server.crt;
ssl_certificate_key /etc/ssl/server.key;
# 2. Требование клиентского сертификата
ssl_client_certificate /etc/ssl/trusted_ca.crt; # Корневой или промежуточный CA, которым подписаны клиентские сертификаты
ssl_verify_client on; # Включаем обязательную проверку
ssl_verify_depth 2; # Глубина проверки цепочки
# 3. Можно извлечь данные из клиентского сертификата для авторизации
location / {
# Например, передать CN (Common Name) клиента в заголовке для бэкенда
proxy_set_header X-Client-Cert-DN $ssl_client_s_dn;
proxy_pass http://backend_app;
}
}
Где мы это использовали: Для безопасного доступа к API между микросервисами в изолированном окружении (service mesh) и для защиты внутренних инструментов вроде Prometheus или Grafana.