[squid-users] Squid Error SQUID_TLS_ERR_ACCEPT -- Transparent proxy

Alex Rousskov rousskov at measurement-factory.com
Thu Oct 9 13:41:37 UTC 2025


On 2025-10-09 00:03, Amos Jeffries wrote:
> On 16/09/2025 08:32, Usama Mehboob wrote:
>> This binary uses OpenSSL 3.2.2 4 Jun 2024.
...
>> 2025/09/14 09:46:34 kid1| ERROR: failure while accepting a TLS 
>> connection on conn122766 local=3.225.139.255:443 
>> remote=172.25.239.18:59114 FD 11 flags=33: 
>> SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000418+TLS_IO_ERR=1

> OpenSSL library error code A000418 means "unknown CA".
> 
> 
> When receiving a certificate chain, Squid found one of the CA was both 
> unknown, and did not provide details on where to fetch it.

OpenSSL library error code A000418 is unknown CA _alert_. In this case, 
it is the _client_ that does not trust Certificate Authority used by 
Squid. The client sends Squid a TLS alert to inform Squid about the problem.

In most cases, to make this work, TLS client or its environment needs to 
be configured to trust Certificate Authority that signed squid.pem 
certificate used for https_port configuration.


Cheers,

Alex.


> Things you can do:
> 
> * Ensure that your machines "ca-certificates" are up to date.
> 
> * Fix the 'mode' issue below with squid.conf.
> 
>   (I believe this is highly likely to be your problem).
> 
> 
> * Try an upgrade to currently supported Squid. v7 these days.
> 
> * use "debug_options 11,2 ALL,1" to see what transactions are being 
> processed.
>    - Then "local=.. remote=.. FD .." on these errors should match 
> (exactly) to a CONNECT message earlier in the log. Telling you what 
> HTTPS server the client was try to connect to.
>    - Use that information to further track down what certificate details 
> are going bad. Ones from client (peek step1) or from server (peek step2).
> 
> 
>>
>> My squid.conf file is this
>> ====================
>> visible_hostname squid
> 
> FYI, The above should be an FQDN and resolvable in what your clients see 
> as the "public" DNS system.
> 
> 
> 
>>
>> http_port 3128
>> http_port 3129 intercept
>> https_port 3130 cert=/path/to/squid.pem ssl-bump intercept
> 
> Mode ("intercept ssl-bump") goes first. This is to ensure that Squid 
> loads the correct certificate type(s) etc.
> 
> 
>   https_port 3130 intercept ssl-bump cert=/path/to/squid.pem
> 
> 
> If the above change makes squid produces certificate validation errors 
> about the CA, that may have been the problem. It needs fixing.
> 
> 
> 
>> http_access allow SSL_ports
> 
> Congratulations, you now have an "open proxy" free use for the entire 
> world.
> 
> I recommend removing this line. The rules you have later restricting 
> access to "localnet" is sufficient to allow LAN clients the access they 
> need.
> 
> 
> 
>>
>> acl instance_metadata dst 169.254.169.254
>> http_access deny instance_metadata
>>
> 
> The above is unnecessary when the proxy is limited to "localnet"  or 
> "localhost" use.  You should be able to remove these once you stop doing 
> the "allow SSL_Ports".
> 
> 
> 
>> acl allowed_https_sites ssl::server_name .domain1.com .domain2.com 
>> .domain3.com
>>
>> acl step1 at_step SslBump1
>> acl step2 at_step SslBump2
>> acl step3 at_step SslBump3
>> ssl_bump peek step1 all
>> ssl_bump peek step2 allowed_https_sites
>> ssl_bump splice step3 allowed_https_sites
>> ssl_bump terminate step2 all
> 
> 
> Okay. FYI, the default step #3 action after "peek step2" should be 
> splice. Which means any traffic reaching step #3 will splice.
>   You can clarify a bit by
> 
> Which is the same as this:
> 
>   # Step 1
>   ssl_bump peek step1
> 
>   # Step 2
>   ssl_bump peek allowed_https_sites
>   ssl_bump terminate step2
> 
>   # Step 3
>   ssl_bump splice step3
> 
> 
> 
>>
>> server_idle_pconn_timeout 60 minute
>> connect_timeout 60 minute
>> read_timeout 60 minute
>> write_timeout 60 minute
>> request_timeout 60 minute
> 
> You might want to add request_start_timeout to that set of extended 
> timeouts.  No use allowing 60 minutes for the first read() of TLS bytes, 
> if Squid is going to abort after 5 minutes of not seeing any HTTP request.
> 
> 
> 
>>
>> logformat fqdn_log %tg:UTC %6tr client:%>a %Ss/%03>Hs %<st %rm %ru 
>> %[un %Sh/%<A %mt %ssl::>sni
>> access_log /var/log/squid/access.log fqdn_log
>>
>> logfile_rotate 10
>> debug_options ALL,1, rotate=1
>>
>>
>> Can somebody please recommend some changes to try out?, also it drops 
>> connection sometime when trying to connect to salesforce BulkAPI and 
>> upon contacting salesforce, their team mentioned that it happens if 
>> client (squid) closes connection before salesforce server. will 
>> appreciate the help. thanks
> 
> 
> Yeah, it seems their service is a bit fragile. Not sure what is going 
> bad there. Their service MUST cope with arbitrary closures, but Squid 
> should not be closing a transaction too-early.
> 
> 
> Maybe an upgrade to v7 will help with that (better code, more things 
> fixed, etc), but no guarantees.
> 
> 
> HTH
> Amos
> 
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users



More information about the squid-users mailing list