Apache HTTPD/mod_proxy/Tomcat y SSL con autenticación de cliente

Question

Estoy seguro de que esta es una pregunta frecuente, pero no pude encontrar nada que reconociera como la misma pregunta.

Tengo varias aplicaciones web ejecutándose en Tomcat, con algunas páginas, p. la página de inicio de sesión protegida por SSL según lo definido por los elementos de confidencialidad en su web.xmls. Una de las aplicaciones también acepta autenticación de cliente mediante certificado. También tengo un esquema de autenticación bastante extenso basado en JAAS &, y hay todo tipo de código compartido y diferentes configuraciones de JAAS, etc. entre las diversas aplicaciones web.

Realmente no quiero molestar a ninguno de los que al realizar el siguiente.

Ahora estoy en el proceso de insertar Apache HTTPD con mod-proxy y mod-proxy-balancer delante de Tomcat como equilibrador de carga, antes de agregar más instancias de Tomcat.

Lo que quiero lograr con las solicitudes HTTPS es que son redirigidas 'ciegas' a Tomcat sin que HTTPD sea el punto final SSL, es decir, HTTPD pasa el texto cifrado directamente a Tomcat para que TC pueda seguir haciendo lo que ya está haciendo con los inicios de sesión , SSL, garantías de confidencialidad web.xml y, lo más importante, autenticación de clientes.

¿Es esto posible con la configuración que he descrito?

Estoy muy familiarizado con los webapps y SSL y HTTPS y Tomcat, pero mi conocimiento de los alcances externos de Apache HTTPD es limitado.

feliz de tener esta movido si es necesario, pero es una especie de programación con archivos de configuración;)

Answer 1

Esta sonidos similares a this question, donde yo he respondido que no es posible:

Puede Simplemente retransmite el tráfico SSL/TLS a Tomcat desde Apache. O bien su conexión SSL termina en Apache, y luego debe revertir el proxy el tráfico a Tomcat (SSL [entre Httpd y Tomcat] rara vez es útil en este caso), o si hace los clientes se conectan a Tomcat directamente y lo dejan manejar la conexión SSL .

Admito que es un poco escaso de enlaces para respaldar esta afirmación. Creo que podría estar equivocado (nunca he visto esto hecho, pero eso no significa estrictamente que no existe ...).

Como ya sabe, necesita una conexión directa, o una conexión completamente retransmitida, entre el usuario-agente y el punto final SSL (en este caso, quiere que sea Tomcat). Esto significa que Apache Httpd no podrá examinar la URL: conocerá el nombre de host en el mejor de los casos (al usar la Indicación del nombre del servidor).

La única opción que no parece depender de una URL en el mod_proxy documentation es AllowCONNECT, que es lo que se utiliza para hacia adelante servidores proxy para HTTPS.

Incluso the options in mod_proxy_balancer esperan una ruta en algún punto de la configuración. Su documentación no menciona SSL/HTTPS ("Proporciona soporte de equilibrio de carga para los protocolos HTTP, FTP y AJP13"), mientras que mod_proxy habla al menos sobre SSL al mencionar CONNECT.

que sugeriría un par de opciones:

• El uso de un iptables basado equilibrador de carga, sin pasar por Httpd, poniendo fin a las conexiones en Tomcat directamente.

• Finalizando la conexión SSL/TLS en Httpd y utilizando un proxy inverso HTTP simple para Tomcat.

Esta segunda opción requiere un poco más de configuración para tratar con los certificados del cliente y las restricciones de seguridad de Tomcat.

Si ha configurado su aplicación web con <transport-guarantee>CONFIDENTIAL</transport-guarantee>, tendrá que hacer que Tomcat señale las conexiones como seguras, a pesar de que las ve venir de su puerto HTTP simple. Para Tomcat 5, here is an article (originalmente en francés, pero las traducciones automáticas no son tan malas) describiendo cómo implementar una válvula para configurar isSecure(). (Si no está familiarizado con valves, son similares a los filtros, pero operan dentro de Tomcat, antes de que la solicitud se propague a la aplicación web. Se pueden configurar dentro de Catalina) Creo que desde Tomcat 5.5, el HTTP connector secure option hace exactamente eso, sin requerir su propia válvula. El conector AJP también tiene una opción similar (si usa mod_proxy_ajp o mod_jk).

Si usa el conector AJP, mod_proxy_ajp reenviará el primer certificado de la cadena y lo pondrá a disposición dentro de Tomcat (a través del atributo de solicitud normal). Probablemente necesites SSLOptions +ExportCertData +StdEnvVars. mod_jk (aunque obsoleto hasta donde yo sé) también puede reenviar toda la cadena enviada por el cliente (usando JkOptions +ForwardSSLCertChain). Esto puede ser necesario al usar proxy certificates (que no tienen sentido sin la cadena hasta su certificado de entidad final).

Si desea utilizar mod_proxy_http, un truco es pasar el certificado a través de an HTTP header (mod_header), usando algo como RequestHeader set X-ClientCert %{SSL_CLIENT_CERT}s. No puedo recordar los detalles exactos, pero es importante asegurarse de que este encabezado esté despejado para que nunca provenga del navegador del cliente (que de otra manera podría hacerlo). Si necesita la cadena completa, puede probar this Httpd patch attempt. Este enfoque probablemente necesitaría una válvula/filtro adicional para convertir el encabezado en el javax.servlet.request.X509Certificate (mediante el análisis de los bloques PEM).

Un par de otros puntos que pueden ser de interés:

• Si recuerdo bien, es necesario descargar los archivos de la CRL explícitamente Httpd y configure it to use them. Dependiendo de la versión de Httpd que esté usando, puede que tenga que llamar al restart it to reload the CRLs.
• Si está utilizando la renegociación para obtener su certificado de cliente, una directiva CLIENT-CERT no hará que Httpd solicite un certificado de cliente por lo que yo sé (esto se hace a través de una válvula que puede acceder al SSLSession cuando usa el Conector JSSE directamente). Es posible que deba configurar la ruta correspondiente en Httpd para solicitar el certificado del cliente.