Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have apache running on one machine as a load balancer:

<VirtualHost *:443>
  DocumentRoot  /home/example/public

  SSLEngine             on
  SSLCertificateFile    /etc/pki/tls/certs/example.crt
  SSLCertificateKeyFile /etc/pki/tls/private/example.key

  <Proxy balancer://myappcluster>
    BalancerMember route=app1
    BalancerMember route=app2

  ProxyPass         / balancer://myappcluster/ stickysession=_myapp_session
  ProxyPassReverse  / balancer://myappcluster/


Note that the balancer takes requests under SSL port 443, but then communicates to the balancer members on a non-ssl port. Is it possible to have the forwarding to the balancer members be under SSL too?

If so, is this the best/recommended way?

If so, do I have to have another SSL cert for each balancer member?

Does the SSLProxyEngine directive have anything to do with this?

share|improve this question

Yes, you're on the right track. You'll want to set up an SSL listener on your backend devices.

You will need certs for them, but it can probably just be self-signed ones - unless you set a SSLProxyVerify command, Apache doesn't care about authenticating them (of course, you can have it verify if you choose)

And yes, set an SSLProxyEngine on, and change your ProxyPass directives to https and the correct new port.

share|improve this answer
Just a quick note - if you're using the default port (443) on your backends don't specify it explicitly, apache will assume 443 if you use https://. I've had issues in the past with ProxyPassReverse not working right because of the redundant :443 being trimmed somewhere along the chain. – Eduardo Ivanec May 4 '11 at 18:09

You don't want to do this. Your Apache HTTPD balancer should be running in the same LAN as the Tomcats so SSL shouldn't be required, and in any case Apache HTTP has to be the SSL endpoint to the client anyway, and also a trusted SSL endpoint to Tomcat. There's no point in the second part of that.

You can configure Apache HTTPD SSL so as to pass on the client certificates etc over AJP so your web-app can't actually tell it isn't SSL, and the degree to which you can customize SSL right down to the directory level in Apache HTTPD makes it a far better place to handle SSL configuration anyway.

share|improve this answer

I found that if you balance SSL to non-SSL Tomcat, then the Tomcat app gets its base set to the non-ssl URL, which seems to cause problems with a mixture of SSL and non-SSL content. Passing SSL to an SSL Tomcat works fine.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.