Грешки в SSL сертификата след пренасочвания с персонализиран CA пакет
Проверете дали изрично избраният CA файл съдържа целия доверителен материал, необходим на действителния път на заявката, включително пренасочените хостове.
CA файлът на компанията коригира първия URL, след което пренасочване не преминава проверката. Проверете дали персонализираната CA опция е заменила предишния доверителен вход на клиента, вместо да го допълни.
Това поведение зависи от TLS бекенда и опцията. Файл, съдържащ само корпоративния CA, може да остави клиента без други органи, от които се нуждае.
- Следвайте всеки участник. Първият хост може да бъде прихванат под корпоративния издател. По-късен хост може да използва обходен път, друг път за инспекция или публично издадена верига.
- Запишете входните данни на неуспешния клиент. Пазете заявеното име на хоста, целта на пренасочването, получения издател, резултата от проверката и избраната доверителна конфигурация. Работещ браузър може да използва друго хранилище за корени.
- Проверете правилата за избор на бекенда. Изгражданията на curl могат да използват вградена проверка или корени на база файлове, а изричните CA опции могат да променят този избор. Рецепта за този изпълним файл не конфигурира Python среда или JVM.
Използвайте поддържан пакет или поддържана подредба на доверително хранилище, съдържаща публичните и частните органи, на които приложението трябва да се доверява. Не добавяйте частния ключ на CA и не повишавайте всеки неуспешен краен сертификат до корен само за да изчистите следващата грешка.
Доставяйте доверителния материал чрез поддържания път за актуализация на внедряването. Ръчната подмяна на доставчикски CA пакет може да бъде отменена от следващата му актуализация; поддържайте собственика и процеса на поддръжка явни, така че проверката да продължава по целия маршрут на заявката.