mTLS в curl: где сертификат клиента, где ключ, а где доверие к серверу

Внутренний API принимает запросы только с клиентским сертификатом. В распоряжении инженера три файла: сертификат клиента, его приватный ключ и сертификат корпоративного центра. Если передать их случайным опциям, curl может довериться серверу, но не предъявить клиентскую идентичность, либо наоборот. Взаимный TLS требует двух независимых проверок.

Назначьте файлам роли

curl --cacert server-ca.pem --cert client.crt --key client.key --connect-timeout 5 --max-time 15 -v https://api.internal.example/health

cacert задаёт доверие к сертификату сервера. cert предоставляет сертификат клиента, key — соответствующий приватный ключ. API проверяет клиентский сертификат по своей политике доверия. Сертификат центра, которому доверяет клиент, не обязан совпадать с центром, которому сервер доверяет при проверке пользователей.

Пример предполагает PEM-файлы и curl с поддерживающим такой способ TLS-backend. Конкретные форматы зависят от сборки. Узнайте backend через curl --version. Для PKCS#12 могут понадобиться другой тип и способ передачи пароля; копировать параметры PEM на такой контейнер без проверки не следует.

Прочитайте, на каком этапе отказ

Если curl не доверяет сертификату сервера, сначала исправьте CA, цепочку или имя. Клиентская аутентификация не отменяет проверку удалённой стороны. Опция insecure скрыла бы эту границу и затруднила разбор, поэтому используйте правильный CA-файл.

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

Если TLS прошёл, но HTTP вернул 403, переходите к авторизации приложения. Сертификат может быть криптографически допустимым, но его субъект не сопоставлен с нужной ролью или операцией. Передайте владельцу API идентификатор сертификата и время запроса; приватный ключ для такого расследования не нужен.

Проверьте границу допуска

На согласованном стенде выполните запрос с разрешённым сертификатом, затем без него. Второй должен дать предусмотренный отказ. Это проверяет, что API действительно требует клиентскую идентичность, а успешный первый запрос не прошёл через случайно открытый альтернативный вход.

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

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

После настройки сохраните срок действия сертификата и порядок его замены. Рабочее mTLS-соединение перестанет открываться после истечения сертификата даже при неизменной сети и полностью исправном сервере.

Развивайте практику проверки серверных доступов. В курсе Linux и Bash для DevOps-инженеров предусмотрены доступы, сеть и HTTP-диагностика. Откройте программу, чтобы связывать файлы доверия, параметры клиента и ответ сервиса в объяснимую процедуру.

Ещё по теме

• Тестируем отдельный backend по HTTPS: curl --connect-to сохраняет имя сервиса
• curl завершился успешно после HTTP 500: сохраняем тело ошибки и код отказа