Mot de passe du keystore perdu, quelles sont mes options?

Question

J'ai un keystore que j'ai utilisé pour générer des fichiers .csr, les ai envoyés et j'ai récupéré .p7b fichiers. Cependant, j'ai réussi à perdre mon mot de passe keystore, j'ai vu qu'il y avait un programme force brute java pour le résoudre mais je sais que mon mot de passe est de 15 caractères et cela prendrait beaucoup de temps. J'ai également essayé de créer un nouveau keystore à partir de l'ancien, comme certaines personnes l'avaient suggéré mais il me faut encore entrer le mot de passe et échouer sans cela.

Suis-je susceptible de rencontrer des problèmes si je crée juste un nouveau keystore et importe les certificats dans celui-ci ou dois-je demander de nouveaux certificats?

Answer 1

Suis-je susceptible de rencontrer des problèmes si je viens de créer une nouvelle et keystore importer les certificats dans ce un

Vous courrez dans le problème que vous ne pouvez pas le faire. Vous avez perdu l'accès à la clé privée.

ou est-ce que je dois demander de nouveaux certificats?

Vous devez créer un nouveau fichier de clés, keypair, la RSE, le faire signer, importer, ...

Answer 2

En fait, il est un peu plus compliqué. Malgré son nom, Java « keystore » peut effectivement contenir toute combinaison de:

• PrivateKeyEntry - contient privatekey et certificat correspondant ou de la chaîne, utilisée pour prouver votre identité propre, en particulier pour une connexion SSL/serveur TLS

• TrustedCertEntry - contient cert, généralement CA cert racine, utilisé pour vérifier autres parties, y compris le protocole SSL/TLS avec le client (s) serveur de vérification (s)

• (uniquement dans certains formats, ne pas JKS communs) SecretKeyEntry - pas pertinent ici

Voir the javadoc for java.security.KeyStore. En fait le 'truststore' des certificats CA utilisés par les clients SSL/TLS (y compris HTTPS) en Java pour vérifier les serveurs est normalement un fichier keystore, par défaut JRE/lib/security/cacerts qui est fourni dans le JRE (pour Oracle -formerly-Sun packages) ou lié (pour OpenJDK, au moins dans les systèmes que j'ai utilisés). Par conséquent, si vous indiquez keytool pour importer vos propres certificats dans un nouveau fichier de magasin de clés, il le fera, mais en tant qu'entrée (s) de certificat approuvé pouvant identifier quelqu'un d'autre, et non en tant qu'entrée de clé privée. vous identifier La seule indication est subtile: keytool dira Certificate was added (ce qui signifie un trustedcert) PAS Certificate reply was installed (ce qui signifie une clé privée correspondante). Si vous utilisez ensuite ce fichier de clés cert-only-not-privatekey pour un serveur SSL/TLS, aucune erreur immédiate ou évidente ne sera générée; Normalement, il rejettera toutes les tentatives de connexion comme «pas de suites de chiffrement en commun». (Si les deux points de terminaison ont été configurés pour autoriser les suites de code «anonymes», la connexion peut/peut réussir avec une suite anonyme, mais cela n'offre aucune sécurité contre les attaques actives courantes et n'est donc généralement pas effectuée.Mais cela ne change pas le résultat: sans le mot de passe et donc l'accès à l'ancienne clé privée, vous êtes coincé et devez recommencer. Notez que si vous avez utilisé une AC payante, beaucoup d'entre eux (IME la plupart) permettent de "rekeying" un CERT pour le même nom de domaine gratuitement ou avec un rabais substantiel.