On 19/01/19 4:31 am, Alex Rousskov wrote: > On 1/18/19 4:35 AM, Dmitry Melekhov wrote: >> >> 17.01.2019 21:02, Alex Rousskov пишет: >>> On 1/16/19 10:30 PM, Dmitry Melekhov wrote: >>> >>>> 2019/01/17 09:18:21 kid1| ERROR: negotiating TLS on FD 55: >>>> error:14090086:SSL routines:ssl3_get_server_certificate:certificate >>>> verify failed (1/-1/0) >>> >>>> In access log: >>>> 1547702300.945 0 192.168.22.229 NONE/503 329 GET >>>> https://lkk-udm.esplus.ru/Services/Auth.asmx/Safe? dm HIER_NONE/- >>>> text/html >>>> 1547702301.304 84 - TCP_MISS/404 162 GET >>>> http://crt.sectigo.com/SectigoRSADomainValidationSecureServerCA.crt-/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff-GETmyip=-myport=0 >>>> - HIER_DIRECT/91.199.212.52 text/html >>> Your Squid (or some helper) appears to be adding an >>> "-/ffff...GETmyip=-myport=0" suffix to the crt.sectigo.com URL, >>> resulting in a 404 response from that server. > >> Yes, I suspected this, there is no helper which can add this, as far as >> I know > These mangled URLs are the expected result of a URL-rewrite/redirector helper written to use the long ago deprecated Squid-1.x version of helper protocol. Being used in a Squid configured to allow whitespace in URLs. When those two features are combined there is no way for Squid to identify garbage after the end of URL in helper 1.0 syntax response, from a v2.x syntax response with whitespace in the URL. Squid-3.5 and later are only backward compatible to the Squid-2.0 helper protocol. The older syntax is no longer supported at all. Details of the Squid helper protocol can be found at <https://wiki.squid-cache.org/Features/AddonHelpers#URL_manipulation>. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
