On Thu, 2015-04-23 at 17:18 +0930, Michael Hendrie wrote: > > > > On 23 Apr 2015, at 4:28 pm, Michael Hendrie <mich...@hendrie.id.au> > > wrote: > > > > > > > > > > > > > On 23 Apr 2015, at 4:21 pm, Amos Jeffries <squ...@treenet.co.nz> > > > wrote: > > > > > > On 23/04/2015 6:29 p.m., Michael Hendrie wrote: > > > > > > > Hi All > > > > > > > > I’ve been running squid-3.4.x in tproxy mode with ssl_bump > > > > server-first for some time and has been working great. > > > > > > > > I have just moved to 3.5.3 to use peek to overcome some issues > > > > with > > > > sites that require SNI to serve up the correct certificate. In > > > > most > > > > cases this is work well however I seem to have an issue that (so > > > > far) > > > > only effects the Safari web browser with certain sites. As an > > > > example, https://twitter.com <https://twitter.com/> and > > > > https://www.openssl.org <https://www.openssl.org/> will result > > > > in a > > > > Safari error page “can’t establish a secure connection with the > > > > server”. There is also a correlating entry in the cache.log > > > > 'Error > > > > negotiating SSL connection on FD 45: error:140A1175:SSL > > > > routines:SSL_BYTES_TO_CIPHER_LIST:inappropriate fallback (1/-1)’ > > > > > > > > > Please try the latest snapshot of 3.5 series. There are some TLS > > > session > > > resume and SNI bug fixes. > > > > > > Thanks Amos, but I did try squid-3.5.3-20150420-r13802 before > > posting….any other suggestions? > > > > Michael > > > > OK, I seem to have resolved this now, for the benefit of everyone else > on the list: > > > In the above tests the generated certificate was being signed by a > RootCA that was installed as trusted in the browser certificate > store. > > > I had previously noticed in my test environment (and thought > completely unrelated) that bumped requests using the new peek/bump in > 3.5.x were not sending the entire certificate chain to the browser but > since they trusted the RootCA that was fine. In my production > environment however I use an IntermediateCA to sign the bumped > requests, this causes a browser error as the clients only trust the > RootCA. As part of investigation to resolve this, I found that adding > ‘cafile=/path/to/signing_ca_bundle’ to the ‘https_port' line (which in > my config is exactly the same file as ‘cert=‘) that all certs are sent > to the client, and I no longer face the issue with Safari and > https://twitter.com or https://www.openssl.org regardless of using > RootCA or InterCA to sign bumped requests. > > > Not sure why but ‘ssl_bump server-first’ sends the entire chain > without specifying ‘cafile=‘ and ‘ssl_bump peek/bump’ doesn’t…but > anyway my problem is solved! > > > Michael > > > > _______________________________________________ > squid-users mailing list > squid-users@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-users
Michael, Could you post your entire config here if possible? Many of us continue to face challenges with ssl_bump and a working config would be great. Thank you. James
_______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
