Cila anë e proxy-t të inspektimit e refuzoi certifikatën?

Klienti i beson proxy-t të inspektimit të miratuar. Kërkesa prapë dështon për shkak të një gabimi certifikate. Të dyja faktet mund të jenë të vërteta: ai proxy ka një lidhje tjetër TLS për të verifikuar.

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

Në një skemë përgjimi, ndërmjetësi e përfundon TLS-in e klientit dhe krijon lidhjen e vet përpara. Klienti mund ta pranojë certifikatën e paraqitur në anën e tij, ndërsa proxy refuzon certifikatën që merr nga faqja e internetit.

Lexoni gabimin e verifikuesit

Përcaktoni cili proces raportoi zinxhirin ose emrin e hostit që dështoi. Një faqe gabimi e krijuar nga proxy mund ta arrijë klientin me sukses përmes një lidhjeje të vlefshme. Ndryshimi përsëri i skedarit CA të klientit nuk e përditëson konfigurimin e besimit lart të proxy-t.

Për shembull, Mitmproxy dokumenton opsione të veçanta besimi lart, duke përfshirë ssl_verify_upstream_trusted_ca. Administratori i duhur mund të konfigurojë besim të miratuar për shërbimin lart duke ruajtur verifikimin. Një produkt tjetër proxy ka nevojë për ndërfaqen e tij përkatëse.

Kontrolloni gjithashtu emrin real të destinacionit dhe zinxhirin. Një shërbim privat pa një ndërmjetës, një certifikatë e skaduar dhe një lëshues privat i panjohur kërkojnë rregullime të ndryshme. Një përjashtim i synuar për një shërbim privat nuk duhet të bëhet në heshtje një pranim global i çdo certifikate.

Një tunel i thjeshtë CONNECT është i ndryshëm

Një tunel opak përcjelljeje nuk e ndan TLS-in e destinacionit në këtë mënyrë. Aplikacioni zakonisht e negocion dhe e verifikon vetë atë sesion TLS nga skaji në skaj. Së pari përcaktoni nëse përgjimi është vërtet pjesë e rrugës, në vend që të aplikoni cilësimet e proxy-t të inspektimit për çdo ndërmjetës.

Regjistroni dy rezultatet e verifikimit veçmas. „Certifikata e proxy-t është e besueshme“ i përgjigjet pyetjes nga ana e klientit; nuk vërteton atë që pa proxy kur u lidh lart.