Ошибки сертификата SSL после перенаправлений с собственным набором CA

Файл CA компании исправляет первый URL, затем перенаправление не проходит проверку. Проверьте, заменил ли пользовательский параметр CA прежние данные доверия клиента, а не добавил к ним.

Это поведение зависит от TLS-бэкенда и параметра. Файл, содержащий только корпоративный CA, может оставить клиента без других нужных ему центров сертификации.

1. Проследите каждого собеседника. Первый хост может перехватываться под корпоративным издателем. Более поздний хост может использовать обход, другой путь инспекции или публично выпущенную цепочку.
2. Запишите входные данные сбойного клиента. Сохраните запрошенное имя хоста, цель перенаправления, полученного издателя, результат проверки и выбранную конфигурацию доверия. Работающий браузер может использовать другое хранилище корневых сертификатов.
3. Проверьте правила выбора бэкенда. Сборки curl могут использовать встроенную проверку или корни на основе файлов, а явные параметры CA могут изменить этот выбор. Рецепт для этого исполняемого файла не настраивает среду Python или JVM.

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

Доставляйте материал доверия через поддерживаемый путь обновления развёртывания. Ручная замена пакета CA поставщика может быть отменена его следующим обновлением; держите владельца и процесс обслуживания явными, чтобы проверка продолжалась на всём маршруте запроса.