> Not exactly. The upstream destination still requires SSL connectivity to be usable - and the client will be faced with certificate domain does not match errors unless yoru peer is also able to perform server-forst bumping when it gets contacted by your Squid.
>
> It looks to me like your peer is receiving plain-HTTP and cannot be "bumped" to supply SSL server cert details.
I have the following setup:
[Internet]
|
[Proxy A]
|
[Proxy B]
|
[Client]
Proxy B has "never-direct allow all" set, so all requests will go via
proxy A.
With SSL bump-server-first disabled, everything works as expected - the
client connects to proxy B and issues a CONNECT command, proxy B
connects to proxy A and issues a CONNECT command, proxy A connects to
the server and the client and server negotiate their SSL sessions
opaquely over the established tunnel.
With SSL bump-server-first enabled, the client connects to proxy B and
issues a CONNECT command, proxy B connects to proxy A and then bombs
with "assertion failed: forward.cc:769: "peer->use_ssl"". Proxy B never
issues a CONNECT to proxy A.
If proxy B is configured to go direct to the server instead of via proxy
A, it behaves correctly.
--
- Steve Hill
Technical Director
Opendium Limited http://www.opendium.com
Direct contacts:
Instant messager: xmpp:steve_at_opendium.com
Email: steve_at_opendium.com
Phone: sip:steve_at_opendium.com
Sales / enquiries contacts:
Email: sales_at_opendium.com
Phone: +44-844-9791439 / sip:sales_at_opendium.com
Support contacts:
Email: support_at_opendium.com
Phone: +44-844-4844916 / sip:support_at_opendium.com
Received on Mon Nov 26 2012 - 22:03:35 MST
This archive was generated by hypermail 2.2.0 : Tue Nov 27 2012 - 12:00:08 MST