Tory,
If you are going to use Certificates from a provider like Verisign
or similar, and will be using an Intermediate cert, will need to chain
them together as to avoid errors from EU web browsers.
Keith
> -----Original Message-----
> From: Amos Jeffries [mailto:squid3@xxxxxxxxxxxxx]
> Sent: Friday, May 02, 2008 7:26 AM
> To: Tory M Blue
> Cc: squid-users@xxxxxxxxxxxxxxx
> Subject: Re: SSL Accel - Reverse Proxy
>
> Tory M Blue wrote:
> > On Thu, May 1, 2008 at 2:02 AM, Amos Jeffries <squid3@xxxxxxxxxxxxx>
> wrote:
> >> You could make a second peer connection using HTTPS between squid
and
> the
> >> back-end server and ACL the traffic so that only requests coming in
via
> SSL
> >> are sent over that link. Leaving non-HTTPS incoming going over the
old
> HTTP
> >> link fro whatever the server want to do.
> >>
> > Thanks Amos
> >
> > Not sure that I made myself clear or that I understand your
suggestion.
>
> You made the situation clear. I mentioned the only reasonably easy
> solution.
> If you didn't understand me, Keith M Richad provided you with the
exact
> squid.conf settings I was talking about before.
>
> Squid can talk HTTPS to the clients, HTTPS to the web server, and
still
> sit in the middle caching files. Exactly as it would for HTTP.
> All you need is SSL certificates for each side of squid. Configured as
> Keith gave you.
>
> >
> > I need to allow squid to connect and talk to my servers via http
> > (only), i want squid to handle the SSL termination (SSL
acceleration,
> > take the overhead off the back end servers).
> >
> > However since squid talks to the back end servers via http (and not
> > https on pages that require https), I need to somehow tell the
server
> > that the original connection, or the connection that will go back to
> > the client will be https, even though the server is responding via
> > http..
> >
> > I handle secure and non secure fine now, the same website for
example.
> > apps.domain.com, listens to both 443 and 80, so squid can handle
> > secure and non secure. there is code on apps.domain.com that checks
> > the incoming protocol to verify that's it's secure, if not it sends
a
> > secure url for the client to come back in on. As you can see if I
> > allow Squid to handle the SSL portion, the back end server has no
way
> > of knowing (the piece I'm missing) if the actual client connection
is
> > secure or not. (hard to explain possibly)..
> >
> > Client ----> apps.domain.com (443) <Squid> ---------> backend server
> (80)
> > backend server (80) ------> <Squid> apps.domain.com (443)
---------->
> > Client (443)
> >
> > I'm wondering if Squid can tell the peer (server) that the original
> > request was in fact secure, so that we can tell the application,
feel
> > free to respond with the secure data via non secure port, because
> > squid will encrypt the server response and get back to the client
via
> > https
> >
> > Sorry kind of long winded.
> > Tory
>
>
> --
> Please use Squid 2.6.STABLE20 or 3.0.STABLE5
