¿Cómo averiguo qué almacén de claves está utilizando mi JVM?


125

Necesito importar un certificado en mi almacén de claves JVM. Estoy usando lo siguiente:

keytool -import -alias daldap -file somecert.cer

así que probablemente necesite cambiar mi llamada a algo como:

keytool -import -alias daldap -file somecert.cer -keystore cacerts storepass changeit

1
Debe importar un certificado en su almacén de confianza JVM , a menos que sea un CSR firmado, en cuyo caso debe importarlo en su propio almacén de claves, y ya debe saber dónde está, de lo contrario no habría podido generar el par de llaves o la RSE.
Marqués de Lorne

Respuestas:


129

Tu almacén de claves estará en tu JAVA_HOME---> JRE -->lib---> security--> cacerts. Debe comprobar dónde está configurado su JAVA_HOME, posiblemente uno de estos lugares,

  1. Computadora ---> Avanzado -> Variables de entorno ---> JAVA_HOME

  2. Los archivos por lotes de inicio del servidor.

En su comando de importación -keystore cacerts (dé la ruta completa al JRE anterior aquí en lugar de simplemente decir cacerts).


66
/ Library / Java / Home / lib / security / cacerts en Mac OS X 10.9
Sam Barnum

9
* "JAVA_HOME ---> JRE -> lib ---> security -> cacerts" Tenga en cuenta la "s" al final, solo para futuros lectores.
Keir Nellyer

44
Entonces, si instalo una nueva versión de Java y JAVA_HOME apunta a un nuevo directorio, ¿tendré problemas con el certificado?
Kirill Yunussov

1
@Murphy: Esto podría ayudarte a stackoverflow.com/questions/5251323/…
kosa

44
esta es la ubicación de la tienda de confianza en lugar de la ubicación de la tienda clave, creo.
usuario2001850

35

Ubicación del almacén de claves

Cada comando keytool tiene una -keystoreopción para especificar el nombre y la ubicación del archivo de almacén de claves persistente para el almacén de claves administrado por keytool. El almacén de claves se almacena de manera predeterminada en un archivo nombrado .keystoreen el directorio de inicio del usuario, según lo determine la propiedad del sistema "user.home". Dado el nombre de usuario uName, el valor de la propiedad "user.home" está predeterminado

C:\Users\uName on Windows 7 systems
C:\Winnt\Profiles\uName on multi-user Windows NT systems
C:\Windows\Profiles\uName on multi-user Windows 95 systems
C:\Windows on single-user Windows 95 systems

Por lo tanto, si el nombre de usuario es "cathy", "user.home" por defecto es

C:\Users\cathy on Windows 7 systems
C:\Winnt\Profiles\cathy on multi-user Windows NT systems
C:\Windows\Profiles\cathy on multi-user Windows 95 systems

http://docs.oracle.com/javase/1.5/docs/tooldocs/windows/keytool.html


¡He estado buscando este ~/.keystorearchivo misterioso ! Si dejé el -keystoreparámetro, no podría averiguar qué keytoolorientación predeterminada del almacén de claves . Seguí buscando otro cacertsen otro lugar de la máquina. No esperaba que keytool se generara ~/.keystoreen el directorio de inicio, ni que se nombrara en .keystorelugar de cacerts. ¡Has completado un espacio en blanco que la gente de Java debería documentar! ¡Gracias!
George Pantazes

26

Mac OS X 10.12 con Java 1.8:

$ JAVA_HOME / jre / lib / security

cd $JAVA_HOME

/Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home

A partir de ahí está en:

./jre/lib/security

Tengo un almacén de claves cacerts allí.

Para especificar esto como una opción de VM:

-Djavax.net.ssl.trustStore=/Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/jre/lib/security/cacerts -Djavax.net.ssl.trustStorePassword=changeit

No digo que esta sea la forma correcta (¿por qué Java no sabe mirar dentro de JAVA_HOME?), Pero esto es lo que tuve que hacer para que funcionara.


16

Puede encontrarlo en su directorio "Inicio":

En Windows 7:

C:\Users\<YOUR_ACCOUNT>\.keystore

En Linux (Ubuntu):

/home/<YOUR_ACCOUNT>/.keystore

44
no tengo este directorio en windows
simgineer

1
Hice un -keygen sin especificar un almacén de claves, esperando que creara uno en el directorio actual, pero lo creó en mi casa como usted dijo. ~ / .keystore ¡No se pudo encontrar por años! :-) Gracias.
Eurospoofer

permítanme agregar que debajo de cygwin se usa la ruta de windows ya que la propiedad java user.homees igual a la $HOMEDRIVE$HOMEPATHestablecida por windows y no $HOMEestablecida por cygwin where HOMEDRIVE=C:yHOMEPATH=\Users\[YOUR ACCOUNT]
user1708042

13

Esto funciona para mi:

#! / bin / bash

CACERTS = $ ( readlink - e $ ( dirname $ ( readlink - e $ ( which keytool ))) /../ lib / security / cacerts )

if keytool - list - keystore $ CACERTS - storepass changeit > / dev / null ; luego  
    echo $ CACERTS
else 
    echo 'No se puede encontrar el archivo cacerts'. > & 2 
    salida 1 fi 

Solo para Linux. Mi Solaris no tiene enlace de lectura. Al final utilicé este Perl-Script:

#! / usr / bin / env perl use estricto ; usar advertencias ; use Cwd qw ( realpath ); 
$ _ = realpath (( grep {- x && - f } map { "$ _ / keytool" } split ( ':' , $ ENV { PATH })) [ 0 ]); morir "No se puede encontrar la herramienta clave" a menos que se defina $ _ ; my $ keytool = $ _ ; impresión


  
  

 "Usando '$ keytool'. \ N" ; 
s / keytool $ / /;
$ _ = realpath ($ _. '../ lib / security / cacerts ');
die "No se pueden encontrar cacerts" a menos que -f $ _;
my $ cacerts = $ _;
print "Importando a ' $ cacerts '. \ n";
`$ keytool -list -keystore" $ cacerts "-storepass changeit`;
morir "No se puede leer el contenedor de claves" a menos que $? == 0;
salir si $ ARGV [0] eq ' - d ';
foreach (@ARGV) {
    my $ cert = $ _;
    s /\.[^.font>+$//;
    my $ alias = $ _;
    print "Importando ' $ cert ' como ' $ alias '. \ n";
    `keytool -importcert -file" $ cert "-alias" $ alias "-keystore" $ cacerts "-storepass changeit`;
    advertir "No se puede importar el certificado: $?" a menos que $? == 0;
}

6

Como mencionó DimtryB, por defecto el almacén de claves está bajo el directorio del usuario. Pero si está intentando actualizar el cacertsarchivo, para que la JVM pueda elegir las claves, entonces deberá actualizar el cacertsarchivo jre/lib/security. También puede ver las claves ejecutando el comando keytool -list -keystore cacertspara ver si se agrega su certificado.


Es bueno saber que el comando keytool agrega la lib/securityruta correcta automáticamente si solo se le da el nombre relativo.
ceving

1
Pero esto no funcionará -importcert. El comando de lista muestra los certificados de todo el sistema, pero el comando de importación genera un nuevo archivo en el directorio actual.
abandono el

1
updatedb; locate cacertsayuda a encontrar dónde están las ubicaciones de instalación de los archivos cacerts.
sjas

5

En Debian, usando la versión de openjdk "1.8.0_212", encontré cacerts aquí:

 /etc/ssl/certs/java/cacerts

Seguro sería útil si hubiera un comando estándar que imprima esta ruta.


1

Para mí, usando la imagen oficial de Docker OpenJDK 12 , la ubicación del almacén de claves de Java era:

/usr/java/openjdk-12/lib/security/cacerts

Eso es un almacén de confianza, no un almacén de claves.
Marqués de Lorne

1
Primero: si lee la pregunta cuidadosamente (y su propio comentario), suena más como un Truststore, donde se debe importar un certificado. En segundo lugar, la diferencia entre el Truststore y el Keystore es bastante desorientadora, y ambos usan el término "Keystore" por cierto, ya que usan el formato de ambos. Tercero: si observa el comando de importación keytool -import -file example.crt -alias exampleCA -keystore truststore.jks, también usa el parámetro -keystore... en mi humilde opinión, no está claro. Y por último pero no menos importante: estaba buscando ese problema exacto, y encontré esa pregunta. Tal vez otros expliquen lo mismo.
jonashackt

Además, todas las demás respuestas también se refieren al llamado "Truststore" que el JDK usa para validar. Entonces, ¿también rechazaste todas las otras respuestas? Ya recibí un voto positivo, así que ya hay alguien a quien mi respuesta ayudó.
jonashackt

0

Encontramos este problema en un Tomcat que se ejecuta desde un directorio jre que se eliminó (casi por completo) después de una actualización automática de jre, por lo que el jre en ejecución ya no pudo encontrar jre ... / lib / security / cacerts porque ya no existía.

El reinicio de Tomcat (después de cambiar la configuración para ejecutarse desde la ubicación diferente de jre) solucionó el problema.


0

Además de todas las respuestas anteriores:

Si actualizar el archivo cacerts en el directorio JRE no ayuda, intente actualizarlo en JDK.

C: \ Archivos de programa \ Java \ jdk1.8.0_192 \ jre \ lib \ security

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.