Necesita ayuda para configurar la cadena de un almacén de confianza de la autoridad (en Tomcat)

Question

en Lead ... No soy un experto, por el momento, en la seguridad de aplicaciones a través de SSL, pero estoy tratando de establecer un entorno de prueba que incluye todos los escenarios posibles que podemos encontrar en la producción. Para esto tengo un árbol de certificados de entidades (CA), que son los emisores de un surtido de certificados de cliente de prueba, y el nodo / certificados de servidor (entorno de prueba compleja que representa los diversos servicios web publicados y otras aplicaciones que se integran con).

La estructura de estos CAs son como sigue: CA raíz, que ha firmado / Sub emitida CA1, CA2 Sub y Sub CA3. Estos submarinos a continuación, han firmado / expedida todos los certificados de los distintos nodos y clientes en el medio ambiente.

Ahora la pregunta .... En almacén de confianza de mi solicitud me gustaría confiar en todo lo firmado por Sub CA1, CA2 y Sub, pero no Sub CA3 (no fiable). ¿Quiere decir esto mi almacén de confianza debe (1) incluyen sólo Sub CA1 y CA2 Sub, o (2) si se incluyen la raíz de CA, Sub CA1, CA2 y Sub?

No sé cuál es la forma correcta de representar esta cadena de confianza en un almacén de confianza. En el futuro también me gustaría añadir un CA4 Sub (también firmado / emitido por la entidad emisora ??raíz), pero añadir que a una lista de revocación de certificados (CRL) para propósitos de prueba.

Antes de tiempo, gracias por cualquier ayuda con respecto a esto. Es muy apreciada.

Answer 1

advertencia: no voy a probar esto, así que espero que mi respuesta es correcta.

Creo que su suposición básica es correcta. No creo que puede confiar selectivamente revocación sin necesidad de escribir código personalizado, por lo que su almacén de confianza sólo debe contener los certificados que son de confianza por completo. Así que deja la entidad emisora ??raíz y elegir la opción (1).

Como se puede ver, tratar de hacer cumplir tal multa de control de acceso de grano es poco adecuado a la de Java (y la mayoría de los demás sistemas) modelo de autenticación basada en certificado X509. Básicamente están diseñados para la verificación de identidad de externalización de Verisign, Thawte, GoDaddy, GlobalSign, etc., para los certificados SSL y certificados de firma de código. Puede soportar otros modelos, incluyendo los certificados de firma propia, pero no sin considerables por adelantado para el dolor y el mantenimiento continuo dolor de cabeza.