HTTPS proxy musí také odesílat svůj řetězec certifikátů

Diagnostikujte chybějící zprostředkující certifikáty na TLS listeneru od klienta k Squidu odděleně od certifikátu cílového webu.

Pokud klienti odmítnou HTTPS proxy ještě před dosažením webu, prozkoumejte řetězec, který listener proxy odesílá. Samotný platný koncový certifikát nemusí poskytnout zprostředkující certifikáty, které klient potřebuje.

  1. Určete kontrolovaný koncový bod. Přečtěte název hostitele v nakonfigurované URL proxy a chybu pro toto spojení. Certifikát listeneru musí tento název pokrývat. Certifikát webu nebo certifikát pro jiný alias IP jej nemůže nahradit.
  2. Zkontrolujte konfiguraci řetězce listeneru. Podporovaná konfigurace OpenSSL v Squidu může zahrnout zprostředkující certifikáty do souboru certifikátu. Potvrďte uspořádání v referenci listeneru pro nainstalovanou verzi Squidu a TLS backend; chování balíčků není jednotné. Příklad TLS listeneru v Squidu 6.13 drží důvěru listeneru odděleně od TLS cíle.
  3. Zkontrolujte důvěru klienta odděleně. Odesílání zprostředkujících certifikátů pomáhá sestavit řetězec, ale klient stále potřebuje zamýšlenou kořenovou kotvu důvěry. Import celého serverového řetězce do kořenového úložiště bez rozlišení je jiná změna než oprava toho, co server odesílá.

Ponechte ověřování zapnuté. Určuje HTTPS proxy, který klient zamýšlel použít. Po ověření tohoto spojení patří pozdější chyba certifikátu webu TLS relaci cíle přes proxy a má vlastní šetření názvu hostitele a důvěry.

Související články