web-dev-qa-db-ger.com

Android-Keystore funktioniert nicht mehr

Vor kurzem hatte ich ein Problem mit einem Schlüsselspeicher. Ich weiß, es gibt bereits viele Fragen zu diesem Problem. Ich habe sie alle gelesen und wütend gegoogelt.

Error:

keytool error: Java.io.IOException: Keystore was tampered with, or password was incorrect
Java.io.IOException: Keystore was tampered with, or password was incorrect
    at Sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.Java:772)
    at Sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.Java:55)
    at Java.security.KeyStore.load(KeyStore.Java:1214)
    at Sun.security.tools.KeyTool.doCommands(KeyTool.Java:885)
    at Sun.security.tools.KeyTool.run(KeyTool.Java:340)
    at Sun.security.tools.KeyTool.main(KeyTool.Java:333)
Caused by: Java.security.UnrecoverableKeyException: Password verification failed
    at Sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.Java:770)
    ... 5 more

Software, die ich verwende:

Java

Java version "1.7.0_21"
Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)

Finsternis

Version: 3.8.0
Build id: I20120502-2000

Aktuelles ADT-Plugin

Neueste Android SDK

Folgendes weiß ich:

  • Ich habe das Passwort nicht verloren und es hat sich nie geändert.
  • Ich kann das Passwort nicht abrufen (ich kenne den Pass).
  • Ich kann eine vorhandene Anwendung nicht mit einem anderen Schlüssel signieren, ohne eine brandneue Anwendung zu veröffentlichen (also kann ich keine Updates veröffentlichen).

Folgendes habe ich getan:

  • Ich habe Eclipse viele Male deinstalliert und neu installiert.
  • Ich habe das Android ADT-Plugin deinstalliert und neu installiert.
  • Ich habe das neueste Android SDK mehrmals entfernt und erneut heruntergeladen.
  • Ich habe JDK7 deinstalliert und neu installiert.
  • Ich habe versucht, die Sicherungen meines Schlüsselspeichers zu verwenden.
  • Ich habe die MD5-Prüfsummen mit "md5sum KEYSTORE" geprüft und mit den Backups verglichen (gleiche MD5-Ausgabe - nicht manipuliert).
  • Ich habe versucht, den Schlüsselspeicher brutal zu erzwingen (ich habe das mir bekannte Kennwort abgerufen).
  • Ich habe einen Testschlüssel erstellt (mit aktuellem Setup) und das Passwort getestet, und es scheint gut zu funktionieren (also hat sich etwas geändert).
  • Ich habe versucht, Android .apk manuell zu exportieren, und habe dann versucht, es zu signieren (Outside of Eclipse).

So exportiere ich eine unterschriebene Bewerbung:

  • Through Eclipse: Exportieren über Datei> Exportieren> Android-Anwendung exportieren.
  • Before JDK7: jarsigner -verbose -keystore KEYSTORE-DATEI ALIAS.
  • Mit JDK7: jarsigner -verbose -sigalg MD5withRSA -digestalg SHA1 -keystore KEYSTORE-DATEI ALIAS.

Was gibt es noch herauszufinden oder auszuprobieren?

  • Einige Verweise/URLs besagen, dass die Datei "trusted.certs" entfernt werden soll.
  • Versuchen Sie, "debug.keystore" zu löschen.
  • Hat die Aktualisierung von Eclipse oder eines der Android-Entwicklungstools Auswirkungen auf meinen Keystore?
  • Würde das Aktualisieren von Java von jdk6 auf jdk7 Probleme verursachen?
  • Könnte sich das mit dem Jarsigner irgendwie geändert haben oder geändert haben?

Vorschläge für Benutzer:

  • Versuchen Sie es mit JDK6, aber ich konnte kürzlich eine Anwendung exportieren.
  • Geprüftes key.store.password oder key.alias.password in meinen local.properties
  • Deaktivieren Sie das Build automatisch in Eclipse und bereinigen Sie Ihr Projekt
  • Entfernen Sie den .metadata-Ordner in Ihrem Arbeitsbereich und löschen Sie alle temporären Ordner.

Zusammenfassung

  • Die Keystores haben sich nicht geändert.
  • Ich habe die Passwörter zu den Schlüsselspeichern,
  • Ich habe kürzlich eine Anwendung erfolgreich mit folgendem Befehl exportiert:
    • Eclipse 3.8 (und Eclipse 4.0+),
    • Neueste Java 7,
    • Aktuelles ADT-Plugin.
  • Mein letzter erfolgreicher Export und Build war vor einigen Wochen mit Eclipse 3.8, den neuesten Android-Tools und Java 7 mit demselben Kennwort.

Update (29.06.14)

  • Ich habe verwendet: keytool -list -keystore KEYSTORE, um erfolgreich nachzuweisen und zu zeigen, dass 3 meiner 4 Schlüssel funktionieren.
  • Ich habe den letzten Schlüssel bruteforced und das Passwort vom Schlüsselspeicher erhalten (Der Pass, den ich bereits kannte), aber das Passwort funktioniert nicht, wenn ich zum Signieren eingebe. Ich habe verwendet: Java -jar AndroidKeystoreBrute_v1.02.jar -m 3 -k KEYSTORE -d WORDLIST.
  • Seltsamerweise, manchmal, wenn ich mein Passwort sehr schnell in Eclipse eingebe, wird mein Alias ​​angezeigt und ich kann meine Anwendung erfolgreich exportieren. (Ich weiß, das ist verrückt).
  • Java-Version aktualisiert.

Wenn ich das Passwort sehr schnell eingebe, funktioniert es manchmal.

Es scheint, als würde ich beim ersten Öffnen von Eclipse und der Eingabe des Passworts den Keystore verwenden.

Wenn alles andere fehlschlägt, muss ich natürlich einen neuen Schlüsselspeicher erstellen. Ich möchte dieses Problem wirklich lösen, ich bin nur nicht sicher, was ich jetzt tun soll, außer mit einem neuen Schlüssel zu veröffentlichen.

Wenn der Schlüssel nicht ordnungsgemäß wiederhergestellt werden kann, kann ich ihn auf Github öffnen.


Lösung (29.06.14):

Ein besonderer Dank geht an Benutzer Erhannis!

Folgendes habe ich getan:

Der Befehl würde jedes Mal einen Fehler bei mir ausmachen: 

keytool -importkeystore -srckeystore old.keystore -destkeystore new.keystore -v

Da Sie mir sagten, dass wir private Schlüssel aus dem Java-Keystore (.jks) extrahieren könnten, habe ich tiefer gegriffen und am Ende eine Variation des Befehls verwendet. Ich folgte den Links, die Sie gepostet haben hier und hier :

keytool -importkeystore -srckeystore old.keystore -destkeystore new.keystore -deststoretype pkcs12

Nach dem Extrahieren des privaten Schlüssels und Speichern als PKCS12, denke ich, entpackte ich meinen privaten Schlüssel und steckte ihn zurück in einen brandneuen Java Keystore:

keytool -importkeystore -srckeystore new.keystore -srcstoretype pkcs12 -destkeystore final.keystore -deststoretype jks

Verweise:

http://developer.Android.com/tools/publishing/app-signing.html#signapp

http://code.google.com/p/Android-keystore-password-recover/

Liste der StackOverflow-URLs, die ich gelesen habe:

Wie gehe ich mit einem verlorenen KeyStore-Passwort in Android um?

Ungültiges Keystore-Problem?

Android: Ich habe meinen Android-Schlüsselspeicher verloren. Was soll ich tun?

Ich habe meine .keystore-Datei verloren?

Kennwort für Keystore vergessen, an Brute-Force-Erkennung denken. Wird der Keystore beschädigt?

Ich habe das Kennwort für die Android-Keystore-Datei verloren.

Problem beim Ausführen meines signierten, freigegebenen Keystores in Eclipse

Android - Passwort für Keystore vergessen. Kann ich die Keystore-Datei entschlüsseln?

Problem mit dem Keystore der Android-Version: "Keystore wurde manipuliert oder das Passwort war falsch"

49
Jared Burrows

Möglicherweise hatte ich das gleiche Problem. Ich habe nie herausgefunden, warum es fehlgeschlagen ist (obwohl ich mich frage, ob es daran lag, dass das Kennwort für den Keystore kürzer als 6 Stellen war), aber ich konnte meinen Schlüssel in einen neuen Keystore kopieren, den ich dann umbenannte, um den alten zu ersetzen. und es funktionierte danach auf mysteriöse Weise (unter Verwendung der neuen Passwörter). Benötigte übrigens das Schlüsselkennwort. In Abwesenheit von https://security.stackexchange.com/a/3795 habe ich Folgendes getan:

  1. keytool -importkeystore -srckeystore old.keystore -destkeystore new.keystore -v
  2. Das neue Kennwort für den Schlüsselspeicher wurde zweimal eingegeben
  3. Schlagen Enter als ich nach dem Passwort für den Quellschlüsselspeicher gefragt wurde (leer gelassen)
  4. Geben Sie das Schlüsselkennwort ein

Nachdem ich überprüft hatte, ob das neue funktioniert, habe ich es einfach über das alte kopiert. Hoffe, es funktioniert für Sie; Viel Glück.

6
Erhannis

Versuchen Sie, den Ordner .metadata in Ihrem Arbeitsbereich zu entfernen, und löschen Sie alle temporären Ordner. Wenn Ihre Keystore-Datei nicht beschädigt ist und Sie versucht haben, Eclipse, ADT, Android SDK und Java SDK ordnungsgemäß neu zu installieren, werden andere mögliche Ursachen für dieses seltsame Problem nicht angezeigt, die Metadaten-Cachedateien und\oder eine temporäre Beschädigung enthalten.

Noch ein Vorschlag

Verwenden Sie Portecle ein Dienstprogramm zum Verwalten und Untersuchen von Schlüsselspeichern, Schlüsseln, Zertifikaten, Zertifikatsanforderungen, Sperrlisten für Zertifikate usw.

3
Silverstorm

Ich hatte das gleiche Problem und habe alles ausprobiert, was in diesem Thread vorgeschlagen wird, aber mein Alias-Passwort konnte nicht gespeichert werden. Der Punkt ist, dass ich absolut sicher war , was das Passwort betrifft, da ich die App bereits viermal aktualisiert hatte. Ich habe die "Keystore wurde manipuliert oder Passwort war falsch" Nachricht erhalten.

Die Lösung

Es scheint, dass bei der Erstellung des Keystores mit Eclipse ein Leerzeichen vor dem Passwort eingefügt wurde!

Dieser böse Fehler wurde anscheinend in einer späteren Version behoben, sodass ich meine App nicht mit dem Passwort signieren konnte, das ich für richtig hielt.

Basierend auf diesem SO link: Ant kann signierte apk nach dem Update auf Android v2 nicht erstellen. Ich würde vorschlagen, dass Sie Fügen Sie vor oder nach Ihrem Passwort ein Leerzeichen ein .

2
Gerhat

Ich werde ein paar mehr Hitze und Versuche vorschlagen.

Geduld haben, diese anzuwenden,

Schritte:

  1. Deaktivieren Sie den Build in Eclipse automatisch (Projekt-> Automatisch erstellen) und leeren Sie Ihr Projekt.
  2. Bauen Sie es erneut auf (Rechtsklick auf das Projekt + Projekt erstellen)
  3. Projekt exportieren.
  4. Wählen Sie Android-Export. (Automatisch für Sie ausgerichtet)
  5. Wähle deinen Schlüssel. Geben Sie das Passwort ein. Alias ​​sollte in der Liste erscheinen. (Achten Sie auf die Feststelltaste). Manchmal geben wir ein korrektes Passwort, aber aufgrund von Kappen schlägt es immer fehl;)
  6. Lass es mich wissen, wenn es für dich funktioniert.

Ich hoffe, das wird dir helfen.

1

Speichern Sie Werte wie key.store.password oder key.alias.password in Ihrer Datei local.properties? Sind beide falsch?

Ich bin neugierig, ob es einen Fehler bei Schlüsseln gibt, die mit JDK6 erstellt und in JDK7 überprüft wurden. Dies würde erklären, warum die neuen Schlüssel, die Sie zum Testen erstellt haben, funktionieren, aber die alten nicht. Versuchen Sie, ein Downgrade auf JDK6 durchzuführen, und prüfen Sie, ob das Problem behoben ist. Andere hatten Jarsigner-Probleme mit JDK7, die nach einem Downgrade auf 6 verschwanden.

0
Alexander Lucas

Ich habe auch dieses Problem vor kurzem bekämpft und alle hier und anderswo aufgeführten Vorschläge ausprobiert. Schließlich habe ich einen dummen Fehler entdeckt, der diesen Fehler an meinem Ende verursacht hat - ich wollte dies hier mitteilen, falls es einem von euch hilft.

Dies ist wahrscheinlicher der Fall, wenn Sie wie ich mehrere Java-Versionen auf Ihrem Computer installiert haben und JRE/JDK zwischen dem Zeitpunkt, an dem Sie den Keystore erstellt haben, und jetzt, wenn Sie versuchen, das APK zu signieren, aktualisiert haben.

Aus irgendeinem Grund verweisen unsere Kompilierungsanweisungen auf den gesamten Java-Pfad wie folgt:

C:\Progra ~ 1\Java\jdk1.6.0_45\bin\jarsigner -verbose -sigalg SHA1mitRSA -digestalg SHA1 -keystore cre80ve.keystore unsigned.apk cre80ve

Einer der oben genannten Vorschläge brachte mich zu der Annahme, dass es sich überhaupt nicht um ein Kennwortproblem handeln könnte, und dass es Inkompatibilitäten der Version sein könnte, die das Problem verursachen. Also habe ich den folgenden Befehl ausgeführt:

keytool -list -keystore cre80ve.keystore

Mit dem Passwort, von dem ich wusste, dass es richtig war, bestätigte es, dass es das richtige Passwort war.

Ich habe dann den expliziten Verweis im Pfad zur (älteren) Java-Version abgelegt. Daher wurde automatisch die neueste Version von Java (in meinem Fall jdk1.8.0_31) abgerufen:

jarsigner -verbose -sigalg SHA1mitRSA -digestalg SHA1 -keystore cre80ve.keystore unsigned.apk cre80ve

Und alles hat gut funktioniert! 

Fazit: Es handelt sich möglicherweise nicht um ein Passwortproblem, sondern um unterschiedliche Java-Versionen oder Android-SDKs, die das Problem verursachen. Denken Sie also daran. 

Denken Sie daran, Ihren Keystore und Ihr Kennwort an einem sicheren Ort zu sichern, sobald es funktioniert :-)

0
Nik Sanghvi

Ich hatte gerade dieses Problem - plötzlich vergaß Android Studio meine Passwörter und verwendete nicht die, die ich in der Gradle-Datei hatte. Ich hatte die gleiche Schlüsseldatei und die gleichen Passwörter für 6 Jahre im selben Projekt! 

Also habe ich sie manuell eingegeben - aber die Überprüfung ist von Zeit zu Zeit fehlgeschlagen. Ich habe ein paar Dinge ausprobiert, wie zum Beispiel das Ungültigmachen von Caches, das Neustarten von Android Studio und das Wiederherstellen einer Sicherung des Schlüsselspeichers, aber nichts half. 

Schließlich versuchte ich aus purer Verzweiflung, das Keystore-Passwort und das Schlüssel-Passwort zu wechseln. Siehe da - es hat funktioniert! Es stellte sich heraus, dass ich die Passwörter gewechselt hatte, als ich sie vor einigen Jahren in die Gradle-Build-Datei eingegeben habe. 

Fazit: Seien Sie nie zu 100% sicher, dass Sie es richtig machen.

0
Magnus W

Mein Alias ​​hat aufgehört zu arbeiten. (Ok, nach ein paar Updates von Android Studio und Java).

Ich habe alle Lösungen aus diesem Thread sowie aus anderen probiert. In meinem Fall war die Lösung überraschend ... Ich habe den Schlüsselspeicher mit wenigen Aliasnamen. Keiner funktionierte außer einem, das ein Passwort wie der Keystore hatte. Aber leider war es nicht der, den ich brauchte. Das brachte mich dazu, ohne Logik nachzudenken ... Ich habe einzelne Aliasnamen mit in einen neuen Keystore kopiert

keytool -importkeystore -srckeystore old.keystore -destkeystore new.keystore -srcalias importantalias

Und dann habe ich das Alias-Passwort in dasselbe wie das Keystore-Passwort geändert:

keytool -keypasswd -keystore new.keystore -alias importantalias

Endlich konnte ich meinen apk unterschreiben ... Es sieht wie ein dummer Fehler aus, der einen Tag Entwicklung verschwenden kann.

0
Malak Pete