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

Клиентот му верува на одобреното инспекциско прокси. Барањето сепак не успева поради грешка со сертификатот. Двата факти можат да бидат точни: тоа прокси има уште една TLS врска за проверка.

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

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

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

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

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

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

Обичниот CONNECT тунел е поинаков

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

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