Tengo un producto que inicialmente usó un almacén de claves en el que el certificado como información del Propietario y del Emisor como "desconocido".
Ahora, por razones de política de seguridad y todavía garantizo la compatibilidad con versiones anteriores, tengo que actualizar la información del Propietario y del Emisor mientras se conserva el par de claves pública / privada original (para la compatibilidad con versiones anteriores).
¿Es posible hacer tal cosa?
TLDR: No puedes modificar un certificado; puede y debe reemplazarlo .
No puedes cambiar nada dentro de un certificado porque está firmado digitalmente precisamente para evitar que alguien cambie algo en él. Sin embargo, puede obtener un nuevo certificado para el mismo par de llaves pero con fechas nuevas, nombres diferentes y posiblemente otros cambios.
Ninguna CA real emite un certificado con el Propietario (que es realmente el Sujeto) o el Emisor que contiene solo 'desconocido', mucho menos ambos, por lo que este es un certificado autofirmado ficticio (marcador de posición) creado por keytool cuando genera un par de llaves.
Si desea obtener un certificado 'real' de una autoridad de certificación establecida y confiable, también conocida como CA, puede hacerlo con keytool ; de hecho, este es el proceso normal :
keytool -genkeypair : crear par de llaves y certificado autofirmado (en el almacén de claves) keytool -certreq : crear solicitud de firma de certificado, también conocida como CSR (para par de claves en el almacén de claves) keytool -importcert : instalar nuevo certificado y encadenar en el almacén de claves Consulte el manual de Java en, por ejemplo, enlace . Los detalles de los pasos 3 y 4 varían según la CA que utilice, y todas las CA que he visto tienen instrucciones personalizadas para emitir un certificado a un sistema Java, a menudo enumeradas bajo Tomcat como el sistema Java "típico", adaptado a eso CALIFORNIA. Efectivamente, ya ha hecho el paso 1 pero con el nombre de sujeto incorrecto, y necesita completar los pasos restantes con una variación:
keytool -certreq agregue la opción -dname 'newnamefields' (use " en Windows) para especificar el nombre del solicitante / sujeto corregido para el CSR. La información general sobre los nombres de certificados se encuentra en la misma página en el encabezado X.500 Nombres Distinguidos . Si este certificado (y clave) será para un servidor SSL / TLS, el nombre del Asunto debe ser o incluir 'CN=servername' donde servername no es el nombre de una persona como se describe en el manual, sino el nombre, o un comodín (solo en el primer componente) que coincide con el nombre, del servidor, ya que se accede a través de los clientes . Para los servidores públicos / de Internet, este suele ser un nombre de dominio completo, también conocido como FQDN o, en casos excepcionales, una dirección IP, pero algunos entornos de intranet o LAN utilizan otros nombres.
De lo contrario: si desea crear un nuevo certificado autofirmado, keytool no tiene una opción para eso; puedes escribir un programa para hacerlo, pero es más fácil, aunque un poco redondeado, usar OpenSSL en su lugar. También puede usar OpenSSL para solicitar un certificado de CA real con algunas opciones que keytool no admite. Si estás en Linux lo más probable es que ya tengas OpenSSL; en otros Unix es posible que necesite instalarlo, casi siempre desde el repositorio / canal / etc normal del proveedor; en Windows (a menos que Windows10 con WSL) deberá instalar el paquete ShiningLight . En resumen esto es:
keytool -importkeystore -srckeystore jksfile -destkeystore tempp12 -deststoretype pkcs12 # convert from Java-only JKS to standardized PKCS12
openssl pkcs12 -in tempp12 -nocerts -out tempkey # convert from PKCS12 to OpenSSL's 'private' PEM format
Para autofirmado: openssl req -new -x509 -inkey tempkey -validity days -out newcert y preguntas de respuesta para el nombre (o en su lugar, especifique -subj 'namefields' ); para obtener más información, consulte man req en Unix o en la web o en una versión anterior, según corresponda . Entonces keytool -importcert -file newcert -keystore jksfile [-alias entry_if_not_mykey]
Para CA firmado: modifique el archivo de configuración de OpenSSL (o una copia) si es necesario, entonces openssl req -new [-config conffile] -inkey tempkey [-subj 'namefields'] -out csrfile luego envíe este CSR a una CA de la misma manera que para Java anterior. Cuando obtenga un nuevo certificado y su cadena, haga uno de los siguientes:
4a. keytool -importcert el (los) certificado (s) de cadena necesarios para una entrada diferente, o para diferentes entradas individualmente desde arriba hacia abajo, luego el certificado EE para la misma entrada, como se describe para Java
4b. combine el certificado EE y sus certificados de cadena, todos en PEM, en un solo archivo, y keytool -importcert toda la cadena en la misma entrada
4c. use openssl pkcs12 -export para combinar tempkey más el (nuevo) certificado y encadénelo en un solo archivo, por ejemplo, newp12 , por man pkcs12 o aquí o anteriormente , luego keytool -importkeystore -srckeystore newp12 -srcstoretype pkcs12 -destkeystore jksfile después de eliminar la entrada anterior, o simplemente eliminar el archivo si esta es la única entrada (deseada)
Lea otras preguntas en las etiquetas certificates key-generation