HTTPS-proxy peab saatma ka oma sertifikaadiahela

Diagnoosi puuduvad vahesertifikaadid kliendi ja Squidi vahelisel TLS-kuulajal eraldi sihtveebisaidi sertifikaadist.

Kui kliendid lükkavad HTTPS-proxy tagasi enne veebisaidile jõudmist, uurige ahelat, mille proxy kuulaja saadab. Üksnes kehtiv lõppsertifikaat ei pruugi anda vahesertifikaate, mida klient vajab.

  1. Tehke kindlaks kontrollitav lõpp-punkt. Lugege seadistatud proxy URL-is olevat hostinime ja selle ühenduse viga. Kuulaja sertifikaat peab seda nime katma. Veebisaidi sertifikaat või mõne muu IP-pseudonüümi sertifikaat ei saa seda asendada.
  2. Kontrollige kuulaja ahela seadistust. Squidi toetatud OpenSSL-i seadistus võib sertifikaadifaili lisada vahesertifikaadid. Kinnitage paigutus kuulaja viites installitud Squidi versiooni ja TLS-tausta jaoks; pakettide käitumine ei ole ühtlane. Squidi 6.13 TLS-kuulaja näide hoiab kuulaja usalduse sihtkoha TLS-ist eraldi.
  3. Kontrollige kliendi usaldust eraldi. Vahesertifikaatide saatmine aitab ahelat üles ehitada, kuid klient vajab endiselt kavandatud juurusalduse ankrut. Kogu serveriahela valimata juurte hoidlasse importimine on teine muudatus kui serveri saadetava parandamine.

Jätke kontrollimine sisse lülitatuks. See tuvastab HTTPS-proxy, mida klient kavatses kasutada. Kui see ühendus on kontrollitud, kuulub hilisem veebisaidi sertifikaadi viga sihtkoha TLS-seansile proxy kaudu, millel on oma hostinime ja usalduse uurimine.

Seotud artiklid