[squid-users] Squid Cache Issues migration from 5.8 to 6.6

[Jonathan Lee]

Side note: I have just found while analyzing Wireshark packets that this A000417 error only occurs with use of the iMac and the Safari browser, this does not occur on Windows 10 with the Edge browser. 

> On Jul 5, 2024, at 09:02, Jonathan Lee <jonathanlee571 at gmail.com> wrote:
> 
> per 
> 
> As the next step in triage, I recommend determining what that CA is in these cases (e.g., by capturing raw TLS packets and matching them with connection information from A000417 error messages in cache.log or %err_detail in access.log).
> 
> 
> I have Wireshark running do I just look for information with ssl.handshake.type == 1
> 
> Or is there a wireshark particular filter you would like ran to help with isolation?
> 
> 
> 
>> On Jul 5, 2024, at 08:23, Jonathan Lee <jonathanlee571 at gmail.com> wrote:
>> 
>> Thanks for the email and support with this. I will get wireshark running on the client and get the info required. Yes the information prior is from the firewall side outside of the proxy testing from the demilitarized zone area. I wanted to test this first to rule that out as it’s coming in from that first and hits the proxy next
>> Sent from my iPhone
>> 
>>> On Jul 5, 2024, at 06:33, Alex Rousskov <rousskov at measurement-factory.com> wrote:
>>> 
>>> On 2024-07-04 19:12, Jonathan Lee wrote:
>>>> You also stated .. " my current working theory suggests that we are looking at a (default) signUntrusted use case.”
>>>> I noticed for Squid documents that default is now set to off ..
>>> 
>>> The http_port option you are looking at now is not the directive I was talking about earlier.
>>> 
>>>> http_port
>>>> tls-default-ca[=off]
>>>>  Whether to use the system Trusted CAs. Default is OFF.
>>>> Would enabling this resolve the problem in Squid 6.6 for error.
>>> 
>>> 
>>> No, the above poorly documented http_port option is for validating _client_ certificates. It has been off since Squid v4 AFAICT. Your clients are not sending client certificates to Squid.
>>> 
>>> According to the working theory, the problem we are solving is related to server certificates. http_port tls-default-ca option does not affect server certificate validation. Server certificate validation should use default CAs by default.
>>> 
>>> Outside of SslBump, server certificate validation is controlled by tls_outgoing_options default-ca option. That option defaults to "on". I am not sure whether SslBump honors that directive/option though. There are known related bugs in that area. However, we are jumping ahead of ourselves. We should confirm the working theory first.
>>> 
>>>> The squid.conf.documented lists it incorrectly
>>> 
>>> Squid has many directives and a directive may have many options. One should not use an directive option name instead of a directive name. One should not use an option from one directive with another directive. Squid naming is often inconsistent; be careful.
>>> 
>>> * http_port is a directive. tls-default-ca is an option for that directive. It is used for client certificate validation. It defaults to "off" (because client certificates are rarely signed by well-known (a.k.a. "default") CAs preinstalled in many deployment environments).
>>> 
>>> * tls_outgoing_options is a directive. default-ca is an option for that directive. It is used for server certificate validation outside of SslBump contexts (at least!). It defaults to "on" (because server certificates are usually signed by well-known (a.k.a. "default") CAs preinstalled in many deployment environments).
>>> 
>>> AFAICT, the documentation in question is not wrong (but is insufficient).
>>> 
>>> Again, I do not recommend changing any Squid configuration directives/options at this triage state.
>>> 
>>> Alex.
>>> 
>