Le fichier de clés est-il le certificat réel ou l'alias le certificat?Présentation du fichier de clés, des certificats et de l'alias
Si j'utilise un alias différent pour signer mon application, va-t-il gâcher des mises à jour sur le marché? Ou devrais-je signer mon application avec un fichier de clés différent pour gâcher les choses? Et où est visible l'info sous alias?
Le fichier keystore généré par Keytool stocke des paires de clés privées et publiques. Chaque paire ou entrée stockée dans le fichier de clés est référencée par un alias unique. En bref:
entrée Keystore = privé + clé publique paire = identifié par un alias
Le keystore protège chaque clé privée avec son mot de passe individuel, et protège également l'intégrité de l'ensemble keystore avec un mot de passe (éventuellement différent). Par exemple, lorsque vous signez une application Android à l'aide de l'option Exporter le package d'application signé de l'outil Android Eclipse, vous devez d'abord sélectionner un magasin de clés, puis sélectionner un alias/entrée/paire unique à partir de ce magasin de clés. . Après avoir fourni les mots de passe pour le fichier de clés et l'alias choisi, l'application est signée et la clé publique (le certificat) pour cet alias est intégrée dans le fichier APK.
Maintenant, pour répondre à votre question, vous pouvez uniquement publier une mise à jour d'une application qui a été signée avec l'alias «foo» en signant à nouveau la mise à jour avec le même alias. La perte du magasin de clés où votre alias est stocké vous empêcherait de publier une version mise à jour de votre application.
Il y a cependant un moyen de signer une application avec un nouvel alias, mais il implique le clonage d'un alias existant dans le keystore en utilisant keytool -keyclone:
crée une nouvelle entrée keystore qui a le même clé privée et chaîne de certificats comme entrée d'origine.
L'entrée d'origine est identifiée par l'alias (qui par défaut est "mykey" si n'est pas fourni). La nouvelle entrée (destination) est identifiée par dest_alias. Si aucun alias de destination n'est fourni à la ligne de commande, l'utilisateur est invité pour cela.
Si le mot de passe clé privée est différent du mot de passe keystore, alors l'entrée ne sera clonée si un keypass valide est fourni. C'est le mot de passe utilisé pour protéger la clé privée associée à l'alias. Si aucun mot de passe clé n'est fourni à la ligne de commande et que le mot de passe de la clé privée est différent du mot de passe du magasin de clés , l'utilisateur est invité à le faire. La clé privée dans l'entrée clonée peut être protégée avec un mot de passe différent, si vous le souhaitez. Si aucune option -new est fournie à la ligne de commande , l'utilisateur est invité à le mot de passe de la nouvelle entrée (et peut choisir de le laisser être le même que pour la clé privée de l'entrée clonée).
Plus d'informations:
http://download.oracle.com/javase/1.5.0/docs/tooldocs/solaris/keytool.html
http://developer.android.com/guide/publishing/app-signing.html
Le site dev suggère d'utiliser le même certificat pour toutes vos applications. Cela signifie-t-il que, tant que j'utilise le même keystore, je peux utiliser n'importe quel alias avec un mot de passe et qu'il ne gâchera pas les mises à jour, car c'est juste une référence? Le fichier de clés réel est la partie importante? – Roger
J'ai réécrit ma réponse pour être plus précis. En bref, vous devez en effet utiliser le même alias pour signer toutes les mises à jour de votre application. –
@Julio Donc, la meilleure pratique serait d'utiliser le même alias pour toutes les différentes applications que vous souhaitez publier, comme le suggère le site de développement? Je ne vois pas de raison de créer un alias distinct pour toutes vos applications. –