On 21/01/15 22:21, Steve Hill wrote: > Probably not very helpful, but it works for me (squid-3.4.10, > Scientific Linux 6.6, bump-server-first, but not using ssl_crtd). I > also can't see anything wrong with the certificate chain. Found the problem. It's only occurring via transparent https - not explicit proxy-bumping of https The index.txt file shows two entries for the same site. V 171122224624Z 7D33A943166DE91162FDEEA69C6E6D7E62054DC3 unknown /serialNumber=TDtNUZuQo4Ts9hs8qd1ksekvefvr7hdo/OU=GT11048499/OU=See www.rapidssl.com/resources/cps (c)14/OU=Domain Control Validated - RapidSSL(R)/CN=*.snap.net.nz+Sign=signTrusted V 171122224624Z 231617D3B75F4C18A238EF42EAFC568BF27A3485 unknown /serialNumber=TDtNUZuQo4Ts9hs8qd1ksekvefvr7hdo/OU=GT11048499/OU=See www.rapidssl.com/resources/cps (c)14/OU=Domain Control Validated - RapidSSL(R)/CN=*.snap.net.nz+Sign=signUntrusted The "signUntrusted" would be via starting the cert learning process with an IP address, whereas the first would have been via knowing in advance it was myaccount.snap.net.nz So what's the root cause? Is this an example of why the peek/splice feature of 3.5 is so important to the success of transparent HTTPS bumping? (ie is it because there wasn't a SNI hostname) -- Cheers Jason Haar Corporate Information Security Manager, Trimble Navigation Ltd. Phone: +1 408 481 8171 PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
