Ստուգող պրոքսիի ո՞ր կողմը մերժեց վկայականը:

Հաճախորդը վստահում է հաստատված ստուգող պրոքսիին: Հարցումը դեռ ձախողվում է վկայականի սխալի պատճառով: Երկու փաստերն էլ կարող են ճշմարիտ լինել. այդ պրոքսին ունի ևս մեկ TLS հարաբերություն՝ ստուգելու:

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

Ընդհատման կարգավորման մեջ միջնորդը ավարտում է հաճախորդի TLS-ը և ստեղծում իր սեփական կապը դեպի առաջ: Հաճախորդը կարող է ընդունել իր կողմում ներկայացված վկայականը, մինչ պրոքսին մերժում է կայքից ստացած վկայականը:

Կարդացեք ստուգիչի սխալը

Որոշեք, թե որ գործընթացն է հաղորդել ձախողված շղթայի կամ հոսթի անվան մասին: Պրոքսիի ստեղծած սխալի էջը կարող է հաջողությամբ հասնել հաճախորդին վավեր կապի միջոցով: Հաճախորդի CA ֆայլը կրկին փոխելը չի թարմացնում պրոքսիի վերևահոս վստահության կարգավորումը:

Օրինակ՝ Mitmproxy-ն փաստագրում է առանձին վերևահոս վստահության ընտրանքներ, ներառյալ ssl_verify_upstream_trusted_ca: Համապատասխան ադմինիստրատորը կարող է սահմանել հաստատված վստահություն վերևահոս ծառայության համար՝ պահպանելով ստուգումը: Մեկ այլ պրոքսի արտադրանք պահանջում է իր համապատասխան ինտերֆեյսը:

Ստուգեք նաև փաստացի նպատակակետի անունը և շղթան: Միջանկյալ վկայական չունեցող մասնավոր ծառայությունը, ժամկետանց վկայականը և անհայտ մասնավոր թողարկողը պահանջում են տարբեր վերանորոգումներ: Մեկ մասնավոր ծառայության համար նախատեսված բացառությունը չպետք է լուռ դառնա յուրաքանչյուր վկայականի համաշխարհային ընդունում:

Սովորական CONNECT թունելը տարբեր է

Անթափանց փոխանցման թունելը այս կերպ չի բաժանում նպատակակետի TLS-ը: Հավելվածը սովորաբար ինքն է բանակցում և ստուգում այդ ծայրից ծայր TLS սեսիան: Նախ պարզեք՝ արդյոք ընդհատումը իսկապես երթուղու մասն է, փոխարենը կիրառելու ստուգող պրոքսիի կարգավորումները ցանկացած միջնորդի վրա:

Գրանցեք երկու ստուգման արդյունքները առանձին: «Պրոքսիի վկայականը վստահելի է» պատասխանում է հաճախորդի կողմի հարցին. այն չի վկայում, թե ինչ տեսավ պրոքսին վերև հաղորդակցվելիս: