Thank you for the response but I think my question is still unanswered. Comments below: On 1/5/2017 16:57, Bruce Rosenberg wrote: > The cafile option specifies the "chain" file squid should send back to > the client along with the cert, exactly as you would normally do with > Apache httpd or Nginx. (For clarity: I'm using 3.5.23. cafile was replaced in squid-4) This may be what cafile is used for but that does not match the directive description. http://www.squid-cache.org/Versions/v3/3.5/cfgman/http_port.html My suspicion is that the description is a confusion between the same option in openssl and web server options (Apache SSLCACertificateFile and similar). What's it really used for? Chain completion, client cert verification or both? > In the example the generated server cert is depth 0, CA2 is depth 1 and > CA1 is depth 2. > If the client has CA1 installed as a trust anchor then technically you > don't need to send CA1 as it is discarded by the client once the trust > relationship for CA2 is established. > It's good practice to send the full chain though as it makes > troubleshooting easier. > From a client perspective you can quickly grab the whole chain with > openssl s_client and check if CA1 is in the trust store. I have to disagree with this. The anchor (CA1) is discarded regardless. It cannot be used. If included it bloats the TLS handshake. Even openssl will discard it and then look in the trusted CA store. I see with a packet cap that the mimicked server cert and the signing cert are both included even without the cafile option specified. So is it safe to say that the referenced wiki page has just become outdated? If cafile is used to fill in the cert chain it wouldn't be needed unless there were additional intermediate certs between the mitm cert and the trusted CA known to the client. (As in CA1 is trusted by clients, CA1 signs CA2 which signs CA3 which is used as MITM cert, cafile=CA2) Thanks for comments. Senor > > On Fri, Jan 6, 2017 at 10:40 AM, senor <frio_cervesa@xxxxxxxxxxx > <mailto:frio_cervesa@xxxxxxxxxxx>> wrote: > > Hello All. > I'd like clarification of the documentation at > http://wiki.squid-cache.org/ConfigExamples/Intercept/SslBumpWithIntermediateCA > <http://wiki.squid-cache.org/ConfigExamples/Intercept/SslBumpWithIntermediateCA> > > In section "CA certificate preparation" it is stated that a file should > be created with "intermediate CA2 followed by root CA1 in PEM format". > CA1 is the cert trusted by the clients. CA2 is used to sign the mimicked > certs. And finally the statement "Now Squid can send the intermediate > CA2 public key with root CA1 to client and does not need to install > intermediate CA2 to clients." > > The specification states that the clients MUST NOT use CA1 provided in > the TLS exchange. CA1 must be (and in this scenario is) already included > in its trusted store of CAs. > > As I understand it, the TLS exchange with the client for a bumped > connection should have the mimicked server cert followed by the > intermediate cert (CA2) and that's all. The client completes the chain > with the already trusted CA1. > > The example file created is used for cafile= option to http_port which > is supposed to be for verifying client certs which is not part of this > scenario. > > This is getting a little long-winded so I'll wait to see what anyone has > to say about my assumptions or understanding. > > Thanks, > Senor > > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > <mailto:squid-users@xxxxxxxxxxxxxxxxxxxxx> > http://lists.squid-cache.org/listinfo/squid-users > <http://lists.squid-cache.org/listinfo/squid-users> > > _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
