So you're saying that the server caches a value which it (itself) generates? I guess if this is true, then there is nothing for mod_proxy (SSL) to cache when it is in the role of the client to the back-end server...? Also, not sure what you mean about "long lived connections in a pool". Last I knew, back-end persistent connections over SSL did not work correctly in Apache 2.2.x. JB On Tue, Jan 27, 2009 at 7:33 PM, Eric Covener <covener@xxxxxxxxx> wrote: > On Tue, Jan 27, 2009 at 6:43 PM, Jeff Ambrosino <jbambrosino@xxxxxxxxx> wrote: >> I'm using Apache as a reverse proxy to a back-end (origin) web server, >> handling SSL traffic. I have SSLSessionCache enabled, which lets the >> Apache server cache the client's public key to prevent the need to >> renegotiate subsequent connections. But my question is whether this >> also helps when Apache itself is the client to the origin web server? >> In other words, is Apache caching the back-end server's public key to >> prevent the need to handshake SSL to the origin each and every >> request? > > You don't cache the servers key, you cache an opaque sesssion ID that > you've previously established. This should not be reused for a long > period of time. > > I don't know if mod_proxy_http + SSLProxyEngine re-uses session IDs, > but it's somewhat moot because it uses long-lived connections in a > pool anyway. > > -- > Eric Covener > covener@xxxxxxxxx > > --------------------------------------------------------------------- > The official User-To-User support forum of the Apache HTTP Server Project. > See <URL:http://httpd.apache.org/userslist.html> for more info. > To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx > " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx > For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx > > --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|