On 1/14/21 1:22 AM, Greg Hulands wrote: > Can you point me to the rough location in code where the certs are sent to the client. I would start with the following log line: > 2021/01/13 18:09:11.655 kid1| 33,5| client_side.cc(2700) sslCrtdHandleReply: Certificate for arstechnica.com was successfully recieved from ssl_crtd You can see the exact code location of each low-level debug statement. Unfortunately, Squid uses a somewhat unusual filename(linenumber) notation for that, but the information is there -- client_side.cc line 2700. After the source code location, Squid prints the function name where the message was generated -- sslCrtdHandleReply. The above line points to a method that receives the (parsed) certificate from the code that talks to the helper. IIRC, Squid then calls Ssl::configureSSLUsingPkeyAndCertFromMemory() to apply the certificate to the client-Squid TLS connection. It would be good to confirm that the certificate Squid applies is the right one and that all the application functions were successful (e.g., Squid may forget to check some OpenSSL function result). This will require some development skills. > I tried with TLS 1.2 with openssl s_client and it returned the certs the same. Noted. You may prefer to test with TLS v1.2 (first) because it may produce simpler debugging logs and create fewer uncertainties. The code mentioned above is used for all TLS versions. Good luck, Alex. >> 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
