Configurar el uso del certificado HTTPS basado en url en Tomcat

Question

Estoy desarrollando una aplicación web que usa certificados de cliente para autenticarse contra Tomcat durante las llamadas al servicio web con Jersey. Esto funciona muy bien hasta ahora, pero necesito una interfaz web en el mismo contexto que me permita administrar esta aplicación. Dado que la configuración SSL es "por contexto", la única opción para que el frontend use https parece ser la instalación de un certificado de cliente para el navegador que accede, que también aparece en el archivo truststore de tomcat (o descartando el uso de https). .

Para ilustrar lo que realmente quiero:

1. https://url-to-webapp/ws <- Should use client certificate 
2. https://url-to-webapp/web <- Should just use a server certificate 

se puede lograr esto de alguna manera en la configuración de Tomcat, o incluso en el código de la aplicación?

actualización

Probé la configuración sugerida por EJP pero ahora no puede conectarse a Tomcat independientemente de mi uso de certificados - parece fallar durante las operaciones de búsqueda o algo así. Sin embargo, si creo un conector HTTP en 8080, me redirige a 8443. Esta es la configuración que estoy usando. ¿Algunas ideas?

tomcat-users.xml

<tomcat-users> 
<role rolename="webservice"/> 
<user username="CN=ClientCert,OU=Corp,O=Corp,L=London,S=London,C=UK" password="" roles="webservice"/> 
</tomcat-users> 

server.xml

<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" 
maxThreads="150" scheme="https" secure="true" 
clientAuth="true" sslProtocol="TLS" 
keystoreFile="c:\tomcat\keys\server.jks" keystorePass="password" 
truststoreFile="c:\tomcat\keys\client.jks" truststorePass="password"/> 

web.xml

[...] 
    <security-constraint> 
     <display-name>ClientCertificateRequired</display-name> 
     <web-resource-collection> 
      <web-resource-name>MyWebService</web-resource-name> 
      <description/> 
      <url-pattern>/webservice/*</url-pattern> 
     </web-resource-collection> 
     <auth-constraint> 
      <description/> 
      <role-name>webservice</role-name> 
     </auth-constraint> 
     <user-data-constraint> 
      <description/> 
      <transport-guarantee>CONFIDENTIAL</transport-guarantee> 
     </user-data-constraint> 
    </security-constraint> 
    <login-config> 
     <auth-method>CLIENT-CERT</auth-method> 
     <realm-name>tomcat-users</realm-name> 
    </login-config> 
    <security-role> 
     <description/> 
     <role-name>webservice</role-name> 
    </security-role> 
    [...] 
    <servlet> 
     <display-name>Webservice</display-name> 
     <servlet-name>Webservice</servlet-name> 
     <servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class> 
     [...] 
      <run-as> 
      <role-name>webservice</role-name> 
     </run-as> 
    </servlet> 
    [...] 

Answer 1

Sólo definir la primera URL como asegurado y que requiere tanto la confidencialidad y una específica rol, y define la aplicación web como la autenticación de cliente SSL. Defina la segunda URL como que no requiere un rol. Esto es todo en web.XML. Luego, defínate un Reino apropiado para verificar identidades y obtener roles de.

Answer 2

Puede configurar Tomcat para usar la renegociación del certificado del cliente (a diferencia de la negociación inicial), de modo que si se solicita o no un certificado del cliente depende de la URL solicitada.

Para hacer esto, necesita usar clientAuth="false" en la configuración del conector y luego <auth-method>CLIENT-CERT</auth-method> en la aplicación web que desea proteger con un certificado de cliente.

Tenga en cuenta que esto utiliza la renegociación y, por lo tanto, es posible que deba ocuparse de los problemas de reintegro de TLS. En resumen, hubo una falla en el protocolo TLS publicada alrededor de noviembre de 2009. La solución de seguridad inmediata fue desactivar la renegociación (a menos que se fuerce la opción no segura) y luego la implementación de RFC 5746. Ver las correcciones de fase 1 y fase 2 en Oracle Java Transport Layer Security (TLS) Renegotiation Issue Readme.

Por lo que estás tratando de hacer, necesitas que se habilite la renegociación, y para que esto sea seguro, deberías usar la versión de JRE 1.6.0_22.