Hey Greg, I am trying to test it with 5.0.4 and it seems that this site works for me with SSL BUMP. The CN and the SAN are the same so it makes sense that it should work the same on your proxy. However I do see that this domain has 2 IP addresses which might affect what you see. I am trying to verify this issue locally. I wrote the next ruby script to help others with some insights. https://github.com/elico/tls-check-script Both ip addresses seem to give the same certificate. I am using openssl to see the certificate: openssl s_client -showcerts -servername arstechnica.com -connect arstechnica.com:443 </dev/null 2>/dev/null | openssl x509 -noout -text Let me know if something specific is seen in your environment. It shouldn't matter too much but, what OS are you running squid ontop and what is "squid -v" output? Thanks, Eliezer ---- Eliezer Croitoru Tech Support Mobile: +972-5-28704261 Email: ngtech1ltd@xxxxxxxxx Zoom: Coming soon -----Original Message----- From: squid-users <squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx> On Behalf Of Greg Hulands Sent: Thursday, January 14, 2021 8:22 AM To: Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> Cc: squid-users@xxxxxxxxxxxxxxxxxxxxx Subject: Re: generate-host-certificates=on fails to generate certificates for _some_ hosts Hey Alex, Can you point me to the rough location in code where the certs are sent to the client. I tried with TLS 1.2 with openssl s_client and it returned the certs the same. Thanks, Greg > On Jan 13, 2021, at 8:44 PM, Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > On 1/13/21 9:47 PM, Greg Hulands wrote: >> I have put the ALL,9 log >> here https://gist.github.com/ghulands/4a689db93fc87f9e7f69174f292f1914 > >> I can see it generates the certificate correctly, > > Agreed. Squid receives (from the helper) a generated certificate with > the right wildcard CN, not a CA certificate. > > >> but couldn’t identify why it didn’t return the cert to the client. > > Yeah... Squid is calling the code that should set the certificate for > the client connection. Unfortunately, I cannot easily tell whether that > code is using the right certificate -- the existing debugging may not > even reveal that detail. > > If you see a different certificate received by the client -- something I > cannot verify from the logs -- then perhaps Squid incorrectly switched > the right certificate to a different one or Squid failed to set the > right certificate but forgot to report the problem (and the CA > certificate from the related context was used?). These are just wild > guesses. > > If you do not get better suggestions for going forward, consider these > last-straw ideas: > > * Testing with a client like openssl, try disabling TLS v1.3. It is > being used by the client in your logs. Perhaps there is something in TLS > v1.3 that requires special handing when talking to the client. I know > that Squid has problems with TLS v1.3 on the Squid-to-server > connections... (In your case, the Squid-to-server connection is TLS v1.2 > AFAICT). > > * Upgrade to the latest v5 or even v6. I see no relevant fixes in v5 but > I could miss them. > > * If you are a developer, add more debugging or use gdb to find out what > happens with the Squid-to-client certificate. Otherwise, find a > developer who can do that for you. > > Sorry I cannot think of any good options here. > > Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
