Certificat d'importation comme PrivateKeyEntry

Je suis de l'installation de SSL sur un serveur Tomcat et suis les instructions de l'émetteur https://knowledge.rapidssl.com/support/ssl-certificate-support/index?page=content&actp=CROSSLINK&id=SO16181 et il précise:

Verify the following information:

The SSL certificate is imported into the alias with the "Entry Type" of 
PrivateKeyEntry or KeyEntry.  If not, please import the certificate into 
the Private Key alias.

Quand j'ai importer le certificat (tomcat), je suis en utilisant:

keytool -import -trustcacerts -alias your_alias_name -keystore your_keystore_filename
-file your_certificate_filename

mais quand je le fais il importe en trustCertEntry

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 3 entries

primaryca, Jul 26, 2014, trustedCertEntry,
Certificate fingerprint (SHA1): <snip>
tomcat, Jul 26, 2014, trustedCertEntry,
Certificate fingerprint (SHA1):  <snip>
secondaryca, Jul 26, 2014, trustedCertEntry,
Certificate fingerprint (SHA1):  <snip>

Comment puis-je créer un alias de tomcat à l'importation comme PrivateKeyEntry?

Vous chaîne ne pas besoin primaryca. Le serveur doit envoyer le certificat du serveur et de tous les certificats intermédiaires nécessaires à la construction d'un chemin d'accès à l'autorité de confiance. C'est au client de faire confiance à l'autorité ou primaryca. Il n'y a rien que vous pouvez faire si le client ne fait pas confiance à l'autorité ou primaryca (autres que de leur demander de confiance).
Ont clarifié - il s'agit du certificat avec l'alias de tomcat qui est le certificat pour le serveur et non pas l'une des certificats d'autorité de certification
Cela paraît utile: Java keytool: importer la clé privée en Java magasin de clés (JKS).

OriginalL'auteur bhttoan | 2014-07-26

  1. 6

    Se débarrasser de la -trustcacerts option. Ce n'est pas un certificat d'autorité de certification. C'est votre certificat. Et utiliser le même alias la clé privée avait déjà.

    OriginalL'auteur user207421

  2. 4

    Ces CA les lignes directrices sont un peu trompeuses. @EJP dit à juste titre que vous ne devriez pas utiliser -trustcacerts de votre certificat.

    En outre, cette autorité de certification document propose d'importer les primaires et intermédiaires certificats d'autorité de certification dans des opérations distinctes, ce qui devrait vous donner un résultat comme ceci:

    primaryca, Jul 26, 2014, trustedCertEntry,
Certificate fingerprint (SHA1): <snip>
secondaryca, Jul 26, 2014, trustedCertEntry,
Certificate fingerprint (SHA1):  <snip>
tomcat, Jul 26, 2014, PrivateKeyEntry,
Certificate fingerprint (SHA1):  <snip>

    Malheureusement, l'importation des certificats d'autorité de certification dans votre keystore comme cela est inutile. (Il serait utile dans un truststore, mais l'autorité de certification que vous utilisez probablement déjà par défaut dans le truststore.)

    Il est utile d'avoir les certificats d'autorité de certification de votre certificat dans le keystore en effet, présenter un dossier de certificat de chaîne de certificats intermédiaires sont nécessaires. Cependant, le keymanager (sauf peut-être une coutume de mise en œuvre) ne sera pas construire la chaîne pour vous, même si c'trouver des certificats d'autorité de certification à côté de votre Certificat d'Entité finale (en PrivateKeyEntry).

    Vous avez besoin d'importer les certificats ensemble, comme une chaîne, contre l'entrée de votre clé privée est. Pour ce faire, concaténer les certificats ensemble dans un fichier texte (format PEM), votre serveur cert en premier, suivi par le cert utilisé pour le délivrer, et ainsi de suite. Ensuite, importez ce fichier dans votre fichier de clés à l'aide de cette clé privée de l'alias. (C'est exactement le même problème que dans cette question, mais avec un certificat de serveur.)

    (Je ne suis pas sûr de savoir si votre CA vous donne votre cert fichier comme une chaîne déjà, mais en général, vous aurez au moins votre cert dans un seul fichier, et l'autorité de certification intermédiaire certs dans un autre. Le document que vous lien semble induire en erreur parce qu'ils ne font aucune mention de plus d'un bloc entre --BEGIN/END CERT--, et pourtant, l'exemple de capture d'écran a une longueur de certificat de 4 contre que seul alias.)

    @Sauteur avec slalom souligné dans un commentaire sur votre question, vous n'avez pas besoin de la "racine" certificat d'autorité de certification (celui qui s'est auto-signé) dans cette chaîne, depuis votre client approuve déjà, ou il n'a aucune raison de lui faire confiance lorsque vous l'envoyer. Il n'est pas mal de l'avoir dans votre chaîne, mais il est inutile, et peut ajouter un peu de surcharge du réseau.

    OriginalL'auteur Bruno

  3. 3

    Vous essayez d'ajouter un certificat et attendre que ça sera la clé privée - sa confusion entre deux choses différentes.

    Généralement, lors de la création du fichier de clés (.jks) comprennent que la clé privée à l'intérieur.
    Si son vide (supprimé), vous devez générer les bundle.fichier p12) à partir de vos clés et des certificats.

    Afin de créer de nouveaux gratuit de clé et de certificat, vous pouvez utiliser cette application de openSSl https://zerossl.com.

    Ensuite, vous avez obtenu une clé et de certificat que vous devez générer (.p12) fichier de paquet: (sur la machine linux)

    openssl pkcs12 -export -in [filename-certificate] -inkey [filename-key] -name [host] -out [filename-new-PKCS-12.p12]

    Maintenant, il suffit d'ajouter le fichier de package (.fichier p12) à un fichier de clés (.jks) en exécutant la commande suivante: 

    keytool -importkeystore -deststorepass [password] -destkeystore [filename-new-keystore.jks] -srckeystore [filename-new-PKCS-12.p12] -srcstoretype PKCS12

    OriginalL'auteur Eitan Rimon