On 15/12/2015 10:26 a.m., Yuri Voinov wrote: > > Hi all. > > Does anybody can tell me - is it possible to use subordinate secondary > CA in squid for SSL Bumping purpose? > > I.e., we have self-signed primary CA for issue subordinate CA, > > subordinate CA we install in squid's setup, > > primary CA certificate install to clients. > > For example. > > For mimicking we'll using subordinate CA, and, in case of subordinate > key forgery, we can use primary CA to revoke subordinate CA and re-issue > them without total replacement primary CA on clients. > > This will seriously increase bumping security procedure, hm? > > I've tried this scheme with 3.5.11, but without success. I suspect its not going to work in the current releases. The more I look at this part of the SSL code the more twisted it appears to be. There are multiple code paths loading certs in different orders for different features and traffic types. I have been trying to clean up those code paths recently, but it is all still a bit tangled to even see which one is handling what type of traffic. AFAICT (so far) both the bumping and reverse-proxy code loads Intermediary certs if they are listed in the cert= PEM file after the cert Squid is using for either signing-cert or as server-cert. Some other code path is loading them from cafile=, it looks like its the main SSL code but I've not yet found how that code path actually happens (grr). With all that looking hopeful, and the certs identified as the secondary chain being attached (everything except the firstprimary/signing cert). I'm not actually finding anywhere sending the actual signing certificate itself during the bumping steps. So Squid may be horribly sending all-but-one of the certs needed, on the assumption that the signing cert is itself installed on the client. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
