Thank you Amos. I agree that adding the anchor is generally harmless and you've chosen your battles wisely. Also thank you Garri. I must have missed your response confirming the same. For current squid versions the wiki page is misleading according to all credible references I can find. Any application failing because the root is missing is buggy itself and that is not a squid problem. There are several very good arguments for excluding it, including to expose bad apps. Trusting a root cert sent from a server is like trusting a politician because all promises end with "trust me". I'll submit a request for the description of cafile/tls-cafile to change and move the discussion to there. Thanks all, Senor On 1/6/2017 2:06, Amos Jeffries wrote: > On 2017-01-06 21:27, senor wrote: >> 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? > > It is used for chain completion. *which* chain is being completed > depends on the traffic mode. > > clientca= should be the one used *only* for client cert verification (I > think). But neither was used consistently in Squid-3, so YMMV based on > the traffic modes. > >> >>> 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) > > That wiki page was incorrect at the time of creation. But the author > refuses to agree that root cert are discarded so I left it there instead > of inciting an edit war. Saving the root CA into the file should be > harmless anyway. > > Amos > > > _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
