Criei um par de chaves usando o seguinte comando:
"%JAVA_HOME%\bin\keytool" -genkeypair -keysize 2048 -alias tomcat -keyalg RSA -sigalg SHA256withRSA
Percebi que há um armazenamento de chaves na pasta jdk/lib/security e outro armazenamento de chaves na pasta jre/lib/security. Presumi que um deles armazenado conteria o par de chaves que acabei de criar. O par de chaves foi criado no keystore padrão que foi criado no diretório de usuários logados.
Minha primeira pergunta é por que o keystore padrão está no diretório de usuários? Isto parece estranho. Posso mover esse keystore?
Minha segunda pergunta é por que tantas lojas de chaves?
Minha última pergunta é: como meu par de chaves é a única chave no armazenamento padrão, devo movê-lo/copiá-lo para outro lugar? Vou precisar que seja assinado por um ICA, então ficar sozinho não parece certo.
Responder1
Java sobrescreve os armazenamentos de chaves padrão em cada atualização (bem, na maioria das vezes ele é instalado em um novo local e apaga o anterior), portanto, toda vez que você atualizar seus pacotes, ele excluirá qualquer chave privada que um usuário tenha criado (já que a atualização poderia também contêm alterações nos armazenamentos confiáveis padrão para descartar CA não confiáveis, etc.), portanto, o padrão (e a maneira mais sensata) é armazenar coisas na pasta do usuário. Dessa forma, isola-se das atualizações. Além disso, seria um problema de segurança se todos os usuários na mesma máquina pudessem acessar as chaves privadas de qualquer outro usuário ou manipular o armazenamento confiável padrão para permitir CA personalizada.
Os certificados do Windows se comportam de maneira semelhante: o padrão é mostrar o armazenamento pessoal do usuário atual. Novas chaves privadas ou certificados confiáveis afetariam apenas o usuário atual, mas a máquina ainda terá os padrões com os quais o Windows foi fornecido (e cada atualização alterará esses padrões, como novas CAs ou não confiáveis).
O que um usuário faz não deve afetar nenhum outro usuário na mesma máquina.
Quanto ao JRE e JDK, o primeiro é para o runningambiente (ou seja, para uso padrão de aplicações), enquanto o segundo é para developmente tem necessidades diferentes. Um servidor de aplicativos precisará do JDK, pois precisa "compilar" páginas semelhantes *.jspem tempo real. O JDK inclui seu próprio JRE, portanto possui sua própria cópia de tudo que o JRE precisa para funcionar. Como pode ser necessário fornecer suporte para clientes (usuários) de maneira diferente do servidor (ou seja, o JRE e o JDK podem estar usando versões diferentes), o compartilhamento de partes comuns pode interferir.
Você pode alterar o keystore (nome e localização) no -keystore file.jksmesmo comando digitado, mas precisará consultar o mesmo arquivo em qualquer outro comando ou configuração para que o java use o mesmo keystore. Como você nomeou o alias tomcat, presumo que você o usará como um keystore para um servidor de aplicativos, portanto, no arquivo server.xml (ou catalina.xml) você precisará configurar o local do keystore.
Os armazenamentos de chaves para um servidor devem estar em um diretório com acesso restrito (leível apenas pelo usuário com o qual o servidor está executando), como /etc/ssl/e similares.
Quanto ao conteúdo do arquivo em si, como você precisa dele assinado, o primeiro é criar um par de chaves autoassinado (como você fez) e depois criar um CSR (solicitação de assinatura de certificado) para enviar ao CA. Depois disso, você deve importar toda a cadeia (o certificado recém-assinado e a cadeia de certificados da sua CA) para o mesmo alias no mesmo keystore. Isso ainda seria uma única entrada no keystore, mas terá vários certificados (e uma chave privada) sob esse alias.
Se o seu servidor não precisar se conectar a outro servidor, esse keystore não deverá conter nenhum outro certificado. E mesmo que seja necessário, você deve ter um armazenamento confiável separado (um segundo armazenamento de chaves, mas apenas com CAs neles, assim como o arquivo cacerts) (ou confiar no armazenamento confiável padrão do JRE, ou até mesmo incluir a CA no mesmo armazenamento de chaves).