<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 23 Apr 2015, at 4:28 pm, Michael Hendrie <<a href="mailto:michael@hendrie.id.au" class="">michael@hendrie.id.au</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class=""><blockquote type="cite" class="">On 23 Apr 2015, at 4:21 pm, Amos Jeffries <<a href="mailto:squid3@treenet.co.nz" class="">squid3@treenet.co.nz</a>> wrote:<br class=""><br class="">On 23/04/2015 6:29 p.m., Michael Hendrie wrote:<br class=""><blockquote type="cite" class="">Hi All<br class=""><br class="">I’ve been running squid-3.4.x in tproxy mode with ssl_bump<br class="">server-first for some time and has been working great.<br class=""><br class="">I have just moved to 3.5.3 to use peek to overcome some issues with<br class="">sites that require SNI to serve up the correct certificate. In most<br class="">cases this is work well however I seem to have an issue that (so far)<br class="">only effects the Safari web browser with certain sites. As an<br class="">example, <a href="https://twitter.com" class="">https://twitter.com</a> <<a href="https://twitter.com/" class="">https://twitter.com/</a>> and<br class=""><a href="https://www.openssl.org" class="">https://www.openssl.org</a> <<a href="https://www.openssl.org/" class="">https://www.openssl.org/</a>> will result in a<br class="">Safari error page “can’t establish a secure connection with the<br class="">server”. There is also a correlating entry in the cache.log 'Error<br class="">negotiating SSL connection on FD 45: error:140A1175:SSL<br class="">routines:SSL_BYTES_TO_CIPHER_LIST:inappropriate fallback (1/-1)’<br class=""></blockquote><br class="">Please try the latest snapshot of 3.5 series. There are some TLS session<br class="">resume and SNI bug fixes.<br class=""></blockquote><br class="">Thanks Amos, but I did try squid-3.5.3-20150420-r13802 before posting….any other suggestions?<br class=""><br class="">Michael</div></blockquote></div><br class=""><div class="">OK, I seem to have resolved this now, for the benefit of everyone else on the list:</div><div class=""><br class=""></div><div class="">In the above tests the generated certificate was being signed by a RootCA that was installed as trusted in the browser certificate store. </div><div class=""><br class=""></div><div class="">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 <a href="https://twitter.com" class="">https://twitter.com</a> or <a href="https://www.openssl.org" class="">https://www.openssl.org</a> regardless of using RootCA or InterCA to sign bumped requests.</div><div class=""><br class=""></div><div class="">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!</div><div class=""><br class=""></div><div class="">Michael</div><div class=""><br class=""></div></body></html>