Файл CA компанії виправляє перший URL, а потім перенаправлення не проходить перевірку. Перевірте, чи власний параметр CA замінив попередні дані довіри клієнта, а не додав до них.

Ця поведінка залежить від TLS-бекенду та параметра. Файл, що містить лише корпоративний CA, може залишити клієнта без інших потрібних йому центрів сертифікації.

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

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

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

Схожі статті