21.01.2019 8:39, Dmitry Melekhov пишет:
18.01.2019 21:08, Amos Jeffries пишет:
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>.
Thank you!
You are absolutely right.
This is redirector, if I disable it, everything works.
Will contact redirector developer.
There is new rejik (rejik.ru) version, if somebody uses it, you can
solve this problem by upgrade.
Thank you!
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
