Која страна инспекцијског проксија је одбила сертификат?

Клијент верује одобреном инспекцијском проксију. Захтев ипак не пролази због грешке сертификата. Обе чињенице могу бити тачне: тај прокси има још једну TLS релацију коју треба проверити.

client -- TLS to approved intermediary -- proxy -- TLS to website -- destination

У аранжману пресретања посредник прекида клијентов TLS и ствара своју везу даље. Клијент може прихватити сертификат представљен на његовој страни, док прокси одбија сертификат који добија са веб-сајта.

Прочитајте грешку провераваоца

Утврдите који је процес пријавио неуспели ланац или име хоста. Страница грешке коју генерише прокси може успешно стићи до клијента преко ваљане везе. Поновна измена клијентове CA датотеке не ажурира проксијеву конфигурацију поверења ка извору.

На пример, Mitmproxy документује одвојене опције поверења ка извору, укључујући ssl_verify_upstream_trusted_ca. Одговарајући администратор може поставити одобрено поверење за услугу ка извору уз задржавање провере. Други прокси производ треба своје одговарајуће сучеље.

Проверите и стварно име одредишта и ланац. Приватна услуга без посредничког сертификата, истекао сертификат и непознати приватни издавач захтевају различите поправке. Намеравана изнимка за једну приватну услугу не сме тихо постати глобално прихватање сваког сертификата.

Обичан CONNECT тунел је другачији

Непрозирни тунел за прослеђивање не дели TLS одредишта на тај начин. Апликација обично сама преговара и проверава ту TLS сесију од краја до краја. Најпре утврдите да ли је пресретање уопште део руте, уместо да поставке инспекцијског проксија примењујете на било који посредник.

Забележите два резултата провере одвојено. „Проксијев сертификат је поуздан“ одговара на питање са клијентске стране; не потврђује шта је прокси видео када се повезао ка извору.