Сбои TLS-сертификатов: процедура реагирования для агента

Ошибка сертификата в API-запросе агента означает остановку, а не мелкую сетевую неисправность. Запрос может передавать bearer-токен, подписанный запрос, данные клиента или инструкции, меняющие состояние в production. Если клиент не может установить, кому принадлежит другая сторона соединения, ему нечего передавать ни один из этих объектов.

Проблему часто решают неправильно: человек под давлением видит истекший сертификат и включает небезопасный флаг. Автономный агент делает такой обход еще опаснее. Он может быстро повторить запрос, последовать инструкции, спрятанной в задаче репозитория, и повторить тот же небезопасный вызов с несколькими учетными данными. Хорошая процедура останавливает запуск, отделяет факты от предположений и возвращает доступ только после того, как кто-то докажет: нужная конечная точка снова получает трафик.

Предупреждение сертификата меняет решение о доверии

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

RFC 6125 описывает, как приложение сопоставляет личность сервиса с идентификатором, обычно с DNS-именем, к которому клиент намеревался обратиться. RFC 5280 описывает проверку цепочки сертификатов: клиент строит цепочку от переданного конечного сертификата через промежуточные сертификаты до доверенного корня. Важны обе проверки. Сертификат может иметь действительную подпись и при этом принадлежать api-attacker.example, а не api.example. Он может содержать правильное имя хоста, но вести к издателю, которого ваша организация никогда не одобряла.

Для трафика агента последствия вполне конкретны. Bearer-токен, добавленный в HTTPS-запрос, становится доступен тому, кто завершает соединение. Запрос, подписанный учетными данными клиента, может разрешить изменение состояния. Ответ API от самозванца может дать инструкцию для следующего действия или испортить рабочий контекст агента. То, что запрос был зашифрован, ничего из этого не меняет.

Считайте такие сообщения связанными с безопасностью, пока команда не установит их причину:

• сертификат истек или еще не начал действовать
• имя хоста или subject alternative name не совпадает
• не удается получить локальный сертификат издателя или проверить первый сертификат
• в цепочке сертификатов обнаружен самоподписанный сертификат
• проверка сертификата завершилась ошибкой после изменения прокси, DNS или сети

Не классифицируйте каждый сбой как активную атаку. Забытый промежуточный сертификат или неправильно установленные часы на ноутбуке часто становятся обычными операционными проблемами. Но начинать нужно с неопределенности, поскольку тот же класс ошибок появляется, когда кто-то перенаправляет трафик или устанавливает неутвержденный прокси перехвата.

Успешное TCP-соединение доказывает лишь, что по адресу кто-то ответил. Успешное TLS-соединение с отключенной проверкой доказывает еще меньше. Проверка личности сервера определяет, может ли запрос к API с учетными данными покинуть компьютер.

Остановите затронутый запуск до сбора сведений

Первое операционное действие, запретить новые запросы с учетными данными к неисправной конечной точке. Приостановите процесс агента, отзовите активную сессию, если ваш слой действий это поддерживает, или уберите разрешение на выполнение действия. Сделайте это до того, как потратите час на обсуждение знакомого вида сертификата.

Сохраните исходную ошибку без изменений. Запишите полное имя хоста и порт, метод запроса без заголовка авторизации, время с часовым поясом, среду выполнения и ее версию, а также процесс, инициировавший вызов. Укажите, через какую сеть работал компьютер и не начался ли сбой после развертывания, продления сертификата, изменения VPN, установки прокси, обновления DNS или изменения управления устройствами.

Не храните такие сведения в разрозненных чатах, если они содержат пути клиентов или тела запросов. Никогда не вставляйте в тикет заголовки авторизации, cookie, закрытые ключи клиентов или полные файлы окружения. Расследование сертификата не оправдывает создание второй утечки секретов.

Используйте короткую запись об инциденте и явно укажите ответственных:

1. Назначьте специалиста, который может остановить агента, и специалиста, отвечающего за конечную точку или сетевой маршрут.
2. Отметьте, дошел ли вызов до этапа добавления учетных данных. Если дошел, считайте учетные данные потенциально раскрытыми, пока не будет установлена личность TLS-сервера.
3. Сохраните идентификатор сессии агента и запись о неудачном действии, затем запретите автоматические повторы для этой конечной точки.
4. Назначьте момент проверки перед восстановлением. Человек, которому нужен рабочий API, не должен единолично решать, можно ли доверять новому корневому сертификату.

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

Не позволяйте агенту «исправлять» проблему доверия, меняя глобальные настройки среды выполнения. Инструкции вроде curl -k, verify=False, общего пользовательского набора центров сертификации или отключения проверки в Node.js нужно воспринимать так же, как запрос на вывод API-токена. Агент не может определить, является ли неожиданный сертификат одобренным изменением, только потому, что в результатах поиска сказано, что такая ошибка встречается часто.

Сохраните сертификат, не передавая секрет

Серверный сертификат можно проверить без аутентификации в API. Используйте незащищенную конечную точку health, если она есть, либо установите соединение и остановитесь до отправки прикладного запроса. Проверяйте с того же компьютера и из той же сети, где возник сбой: настройки прокси, корпоративные корни доверия и разделенный DNS часто различаются на разных машинах.

Эта команда передает через SNI имя предполагаемого сервера, проверяет запрошенное имя хоста, показывает сертификаты от другой стороны и завершается ошибкой при проблемах с проверкой:

openssl s_client \
  -connect api.example.com:443 \
  -servername api.example.com \
  -verify_hostname api.example.com \
  -verify_return_error \
  -showcerts </dev/null

При успешной проверке вывод заканчивается примерно так:

Verification: OK
Verify return code: 0 (ok)

При сбое сохраните вывод как ограниченное для доступа свидетельство инцидента. Полезны subject, issuer, даты Not Before и Not After, альтернативные имена субъекта и каждый сертификат цепочки. Блоки PEM позволяют владельцу конечной точки сравнить то, что получил ваш компьютер, с тем, что должен отдавать сервер. Это публичные сертификаты, но обращаться с записью нужно аккуратно: имена хостов и внутренние издатели тоже могут раскрывать сведения об инфраструктуре.

Затем проверьте обычное поведение клиента без заголовка авторизации:

curl --verbose --fail --show-error \
  https://api.example.com/health

Подробный вывод показывает версию TLS, выбранный сертификат и сообщение о проверке. Скрывайте пути запросов, если они раскрывают имена арендаторов. Не добавляйте -k, чтобы команда завершилась успешно. Неудачная проверка и есть нужное вам свидетельство.

Частая диагностическая ошибка, не указать -servername. Размещенные сервисы часто выбирают сертификаты по SNI и возвращают сертификат по умолчанию, если клиент его не передал. Так появляется несовпадение имени хоста, которого не было у настоящего клиента. Другая ошибка, запускать openssl s_client без -verify_hostname, а затем считать результат проверки цепочки доказательством совпадения имени. Это не так.

Отдельно запишите разрешенный адрес с помощью обычного инструмента диагностики DNS. Не сводите всю проверку к совпадению адреса. Крупные провайдеры законно используют множество адресов, а злоумышленник может управлять правдоподобным ответом DNS. Сертификат, путь издателя, сетевой маршрут и одобренная запись об изменении вместе показывают, что произошло.

Определите тип сбоя до выбора исправления

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

Истекший сертификат обычно означает, что оператор конечной точки пропустил продление или не установил обновленный конечный сертификат. Сверьте период действия сохраненного сертификата с надежными часами. Ошибка часов может сделать действующий сертификат просроченным или еще не действующим, поэтому сначала проверьте время на клиенте.

Несовпадение имени хоста означает, что сервер не доказал владение именем, которое запросил клиент. Обычно причиной становятся неправильный базовый URL API, ошибка настройки SNI, виртуальный хост по умолчанию, устаревший DNS или сертификат прокси для другого имени. Не принимайте альтернативное имя только потому, что оно похоже на нужное. api.example.com и api.internal.example.com могут обозначать разные сервисы и границы доверия.

Неизвестный издатель может означать, что клиенту не хватает легитимного частного корневого или промежуточного сертификата. Но это также может быть сертификат, выпущенный неутвержденным устройством проверки TLS. Сравните издателя и цепочку с опубликованными или записанными данными о развертывании через независимый канал. Сообщение из той же системы, которая выдала ошибку, не считается независимым подтверждением.

Неполная цепочка обычно указывает на проблему конечной точки. Сервер должен отправлять конечный сертификат и необходимые промежуточные сертификаты. На клиентах должны находиться только корни доверия. Установка недостающего промежуточного сертификата локально может скрыть неправильную настройку сервера на одной машине и оставить всех остальных вызывающих клиентов без исправления. Попросите владельца сервера отдавать правильную цепочку.

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

К отзыву сертификатов нужно относиться внимательно. Многие клиенты не выполняют надежную онлайн-проверку отзыва в каждой среде, а сетевые сбои могут влиять на такие проверки. Не заявляйте, что сертификат безопасен, только потому, что обычное соединение завершилось с кодом 0 (ok). Если владелец сообщает о скомпрометированном закрытом ключе или отозванном сертификате, заблокируйте конечную точку, замените раскрытые учетные данные и установите новую конфигурацию.

Разделите серверный маршрут и маршрут через прокси

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

Проверьте настройки прокси в среде вызова, не выводя значения, которые могут содержать секреты. В Unix-подобной оболочке эта команда печатает только имена заданных переменных прокси:

for n in HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY http_proxy https_proxy all_proxy no_proxy; do
  [ -n "${!n}" ] && printf '%s is set\n' "$n"
done

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

Также проверьте изменения разрешения имен и маршрутизации. Устаревшая запись DNS после миграции может направлять запросы на старый балансировщик, который показывает снятый с использования сертификат. Разделенный DNS может возвращать офисным устройствам внутренний адрес с частным сертификатом, а остальным, публичный адрес. Такие схемы можно исправить, но клиент должен доверять издателю, соответствующему маршруту, и по-прежнему проверять запрошенное имя хоста.

Не обходите проблему, жестко задавая IP-адрес. Проверка HTTPS использует DNS-имена, а прямой IP может обойти нужную маршрутизацию, нарушить выбор SNI или скрыть проблему управления DNS. Подмена IP иногда полезна для строго контролируемой диагностики, но требует согласования с владельцем конечной точки и никогда не должна становиться постоянной настройкой агента.

Прокси создают и вопрос управления данными, на который одна ошибка сертификата не отвечает. Если прокси завершает TLS, он может читать тела API-запросов и добавленные учетные данные. Команда безопасности должна решить, разрешена ли такая проверка для данного API. То, что конечная точка снова работает, ничего не говорит о допустимости нового маршрута.

Делайте доверие к частному центру узким и проверяемым

Частные центры сертификации решают реальные задачи внутренних API, сред разработки и контролируемых сервисных сетей. Проблемы начинаются, когда команды неформально распространяют корни и забывают, какие процессы им доверяют. Корневой сертификат дает владельцу широкие полномочия выпускать идентификаторы внутри своей зоны доверия, поэтому его добавление является административным изменением безопасности, а не простой настройкой совместимости.

Устанавливайте утвержденный частный корень через управляемую операционную систему, образ контейнера или хранилище доверия приложения, которое отвечает за вызов. Запишите subject корня, отпечаток, владельца, предполагаемые DNS-суффиксы, дату согласования и способ удаления. Ограничьте область доверия, если среда выполнения это позволяет. Центр сертификации разработки не должен незаметно стать доверенным для каждого production-агента на каждой машине.

Не доверяйте одному конечному сертификату как замене отсутствующего процесса управления центром сертификации. Доверие к конечному сертификату ломается при продлении и побуждает людей вставлять строки PEM в репозитории. Кроме того, становится трудно отличить запланированную замену сертификата от неожиданной подмены. Если вы управляете обеими сторонами, создайте процесс частного центра сертификации с защищенным ключом подписи, документированной выдачей и плановой ротацией.

Взаимная TLS-аутентификация добавляет отдельное направление идентификации. В обычном HTTPS клиент проверяет сертификат сервера. В mTLS сервер также запрашивает сертификат клиента. Ошибка вроде «alert certificate required» или «bad certificate» может означать, что клиент не передал собственный сертификат, предъявил сертификат от неправильного издателя или не имеет соответствующего закрытого ключа. Отключение проверки сервера здесь не поможет.

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

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

Возвращайте доступ только после независимой проверки

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

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

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

Если есть вероятность, что токен, подписанный запрос или учетные данные mTLS при предыдущем сбое попали к самозванцу, замените эти учетные данные до возобновления обычной работы. Команды часто сопротивляются ротации, потому что свидетельства неполны. Это неверный подход. Именно неполные сведения требуют считать учетные данные, прошедшие через непроверенное соединение, раскрытыми.

Запишите точное исправление, а не расплывчатый вывод вроде «TLS исправлен». Полезная запись сообщает, что оператор конечной точки установил промежуточный сертификат, управляемое хранилище доверия получило конкретный утвержденный корень или настройка прокси была удалена. В ней также указано, кто проверил имя хоста и какие запуски агента были возобновлены. Такая запись не позволит следующему специалисту снова включить небезопасный обход при очередном продлении сертификата.

Сделайте безопасный путь проще обхода

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

Sallyport может хранить API-учетные данные в зашифрованном хранилище и выполнять HTTP-запросы для агента, поэтому агент не получает сами учетные данные. Его записи сессий и вызовов также могут сохранять сведения о том, кто инициировал действие, но решение о том, является ли изменившийся сертификат утвержденным изменением или опасным маршрутом, все равно принимает человек.

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

Обычно первым стоит сделать скучное исправление: удалить уже имеющийся в скриптах небезопасный флаг проверки и настроить обычный клиент на управляемое хранилище доверия. Затем проверьте продление сертификата до того, как это произойдет в production. Команды, которые заранее отработали одно продление и один инцидент с неожиданным издателем, реагируют быстрее команд, чей единственный план по TLS, команда, скопированная с форума.

Предупреждение сертификата выполнило свою задачу, если остановило запрос, который не должен был продолжаться. Пусть так и остается.