¿Es una mala práctica usar el almacén de claves estándar de Java

? Hemos estado utilizando el almacén de claves estándar de Java ($JAVA_HOME/jre/lib/security/cacerts) como el almacén de confianza para tomcat. Y ese servidor Tomcat se comunicaría con algún otro servidor. Una actualización reciente del sistema operativo (AIX) aparentemente sobreescribió el archivo al $JAVA_HOME/jre/lib/security/cacerts y resultó en la pérdida de certificados y muchos problemas con la aplicación alojada en tomcat.¿Es una mala práctica usar el almacén de claves estándar de Java

En cuanto a esto, ¿es una mala práctica repasar $ JAVA_HOME/jre/lib/security/cacerts? ¿Cuáles son las formas alternativas (mejores | estándar) para abordar este escenario?

Fuente

2011-10-25 ring bearer

java_home puede variar según la plataforma, querrá tener cuidado con eso. Yo personalmente buscaría una carpeta de colmena diferente. – Tim

En términos de lo que está en el archivo cacerts, no es necesariamente una práctica peor que confiar en los certificados CA predeterminados instalados en su sistema operativo o su navegador, pero eso no significa que sea genial.

Sun/Oracle tiene un poco de "Nota importante" en algún lugar en medio de la JSSE Reference Guide about this:

NOTA IMPORTANTE: Los barcos de JDK con un número limitado de confianza raíz certificados en el directorio/lib/security/archivo cacerts. Como documentados en keytool, es su responsabilidad mantener (es decir, add/remove) los certificados contenidos en este archivo si utiliza este archivo como almacén de confianza.

Dependiendo de la configuración del certificado de los servidores con los que contacte, , puede que necesite agregar certificado (s) raíz (es) adicional (es). Obtenga el certificado raíz específico del proveedor apropiado.

En términos de configuración, para aplicaciones específicas en las que he tenido que instalar certificados CA "locales", creo que es más estable para utilizar un almacén de confianza local (por ejemplo, especificado con javax.net.ssl.trustStore).

Fuente

2012-01-18 02:32:57 Bruno

No estoy seguro, pero suponiendo que sus suposiciones son correctas, advierta dónde coloca el almacén de claves. Yo sugeriría encarecidamente que se coloque dentro de la carpeta Apache.

De forma predeterminada en el almacén de claves Websphere funciona de esta manera, ya que trae su propia JVM :)

Fuente

2011-10-25 20:31:29

GlassFish también tiene su propio almacén de claves y cacerts. – Hiro2k

No es una mala práctica si tiene un proceso de construcción que se repetirá las importaciones.

Fuente

2011-10-25 23:13:28 EJP

Sí, es una mala práctica hacerlo.

La mejor práctica es limitar sus certificados de confianza tanto como sea necesario.
Así que debería haber utilizado su propio almacén de claves con solo los certificados de confianza de su aplicación.

Fuente

2011-10-28 20:05:40 Cratylus

Eso viola todo el propósito de PKI. La idea es que la presencia de raíces confiables permita que se forme una cadena de confianza para que pueda confiar en cualquier certificado firmado por una CA confiable. Está combinando autenticación, que es para lo que PKI y certificados son, con autorización, que es un problema de dominio de aplicación.Está fundamentalmente roto combinar estas dos funciones separadas. – EJP

@EJP: cuando tiene un punto final que se comunica solo con entidades específicas en una red, ¿por qué permitiría que los certificados sean confiables que sean confiados por * cualquier * CA configurada en mi sistema (ya sea Linux, certificados de java, certificados de Windows? etc.)? – Cratylus

La actualización de AIX es un parche. Cualquier parche no debe eliminar/sobrescribir los datos del usuario. Sugeriría que los usuarios afectados por este tipo de pérdida de datos pidan a IBM que arregle el procedimiento de parche. En comparación, un parche del servidor httpd no sobrescribe/elimina la configuración aunque esté en el directorio del programa.

Fuente

2016-02-21 23:09:00 user250343

¿Es una mala práctica usar el almacén de claves estándar de Java

Respuesta

Cuestiones relacionadas