В чем разница между клиентскими и серверными SSL/TLS сертификатами?

«В чем разница между клиентскими и серверными SSL/TLS сертификатами?» — вопрос из категории Безопасность, который задают на 23% собеседований Devops Инженер. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

Оба типа сертификатов используются для аутентификации в рамках 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.