Problem mit .java.policy

fischauge · 1. April 2014 um 23:54

Hallo!
Um mir die Arbeit zu vereinfachen habe ich mir ein Applet erstellen lassen, was vom Server geschickte Dateien lokal auf meiner Platte speichert. Damit es die Berechtigung hat, habe ich in meinem Windows Userverzeichnis die Datei .java.policy mit folgendem Inhalt erstellt:

grant codeBase "http://www.xyz.de/java/" { permission java.io.FilePermission "<<ALL FILES>>", "write"; };

Seit einem der letzten Java Updates klappt das aber nicht mehr. Konsolenmeldung:

java.security.AccessControlException: access denied („java.io.FilePermission“ „d:\datei.pdf“ „write“)

Was hat sich da bei Java geändert? Wie kann ich wieder erreichen, dass mein Applet die Berechtigung erhält?

Vielen Dank

L-ectron-X · 2. April 2014 um 00:58

Müssen Applets jetzt nicht generell signiert sein?

Sen-Mithrarin · 2. April 2014 um 02:20

1)@Lex: Soweit mir bekannt (7u51 und 8) : ja, müssen sie.
2)@TO: Man kann sich auch die WebStart-API zu nutze machen und so bei jedem “save File” sich explizit die Erlaubnis des Users holen. Das ist dann soweit auch “sicher” und wird dann als berechtigte Aktion zugelassen. Nachteil : man muss wirklich bei jedem File erneut nachfragen und ist, wie der Name schon sagt, eigentlich mal eher für WebStart-Apps gedacht, funktioniert aber auch in nem Applet.

L-ectron-X · 2. April 2014 um 02:30

Im Wiki gibts einen Beitrag: http://wiki.byte-welt.net/wiki/Applets_und_WebStart-Anwendungen_signieren
Unter Punkt 2 (Die Alternative) wird das im Oracle-Link beschrieben, was Sen-Mithrarin angeschnitten hat.

Edit
Zu Java-Applets müssen signiert sein / Java-Applets einbinden: http://www.heise.de/developer/artikel/Java-foerdert-nun-signierte-Applets-1840305.html

fischauge · 2. April 2014 um 03:02

Diese Tipps waren Gold wert, danke euch, bin ein kleines Stück weiter. Habe eine manifest Datei erzeugt, ein neues jar File erzeugt und dann signiert.
Aber leider kommt trotzdem das hier:

Ein Klick auf „Ausführen“ führt es leider trotzdem nicht aus.
Hier der Test:

C:\Program Files (x86)\Java\jdk1.7.0_51\bin>jarsigner -verify -verbose -certs s:\verz\localfile.jar
       0 Wed Apr 02 11:48:44 CEST 2014 META-INF/
      65 Wed Apr 02 11:48:44 CEST 2014 META-INF/MANIFEST.MF
    7527 Wed Dec 14 15:09:26 CET 2011 s:/verz/localfile.class
s = signature was verified
m = entry is listed in manifest
k = at least one certificate was found in keystore
i = at least one certificate was found in identity scope

jar is unsigned. (signatures missing or not parsable)

Was mache ich denn da falsch?

L-ectron-X · 2. April 2014 um 03:04

Kann sein, dass du die Sicherheitseinstellungen deiner lokalen Java-Installation (JRE) noch etwas “lockern” musst.
Allerdings steht da jetzt was von unsigned…

fischauge · 2. April 2014 um 03:07

Ich glaube, es gibt noch ein Problem mit der Signatur, hab noch was im letzten Beitrag ergänzt.

L-ectron-X · 2. April 2014 um 03:41

Guck mal mit einem Packprogramm ins Jar-File (ist nur eine modifizierte Zip-Datei) und guck mal ins META-INF.
Gibts da Schlüsseldateien? (.dsa oder .ds)

fischauge · 2. April 2014 um 03:51

Ja, eine LOCALFIL.DSA
Mein Alias ist localfile

*** Edit ***

Aktuell sieht das jar so aus:

C:\Program Files (x86)\Java\jdk1.7.0_51\bin>jarsigner -verify -verbose -certs s:\verz\localfile.jar

s k 156 Wed Apr 02 12:49:20 CEST 2014 META-INF/MANIFEST.MF

  X.509, CN=My Name, C=de (localfile)
  [certificate is valid from 02.04.14 12:28 to 30.03.24 11:28]

     334 Wed Apr 02 12:49:20 CEST 2014 META-INF/LOCALFIL.SF
     866 Wed Apr 02 12:49:20 CEST 2014 META-INF/LOCALFIL.DSA
       0 Wed Apr 02 12:47:44 CEST 2014 META-INF/

smk 23121 Fri Dec 16 16:58:00 CET 2011 s:/verz/localfile-quellcode.java

  X.509, CN=My Name, C=de (localfile)
  [certificate is valid from 02.04.14 12:28 to 30.03.24 11:28]

s = signature was verified
m = entry is listed in manifest
k = at least one certificate was found in keystore
i = at least one certificate was found in identity scope

jar verified.

Warning:
This jar contains signatures that does not include a timestamp. Without a timestamp, users may not be able to validate this
jar after the signer certificate’s expiration date (2024-03-30) or after any future revocation date.

L-ectron-X · 3. April 2014 um 08:28

Und das oben gezeigte Fehlerfenster erscheint immer noch?

Also, das Zertifikat erscheint mir hier als gültig, das Jar-File wurde aber dennoch nicht valide signiert? Ich weiß erstmal nicht, was es mit dem fehlenden Timestamp auf sich hat. :reflect:
Streiche mal für den Anfang die Option -validity 3650 in Schritt 3 der Batchdatei aus deinem keytool-Befehl. Standardmäßig sollte dann ein Zertifikat mit einer Gültigkeit von einem halben Jahr erzeugt werden.

Ändert sich dann etwas?

fischauge · 3. April 2014 um 10:05

Ja
Was ich noch merkwürdig finde, Java sucht die Datei auf dem Server als /java/localfile/jar.class (sehe ich im error.log)
Das ist Quatsch, denn der Aufruf auf der Webseite sieht so aus:

<applet width="1" height="1" code="localfile.jar" codebase="../java">

Ich weiss nicht, wie ich herausfinde, ob es valide signiert ist?

[QUOTE=L-ectron-X;91185]Ich weiß erstmal nicht, was es mit dem fehlenden Timestamp auf sich hat. :reflect:
Streiche mal für den Anfang die Option -validity 3650 in Schritt 3 der Batchdatei aus deinem keytool-Befehl. Standardmäßig sollte dann ein Zertifikat mit einer Gültigkeit von einem halben Jahr erzeugt werden.[/quote]
Nein, es ändert sich nichts:

C:\Program Files (x86)\Java\jdk1.7.0_51\bin>jarsigner -verify -verbose -certs s:\verz\localfile.jar

s k 156 Thu Apr 03 18:53:54 CEST 2014 META-INF/MANIFEST.MF
  X.509, CN=Mein Name, C=de (localfile)
  [certificate is valid from 02.04.14 12:28 to 30.03.24 11:28]

     334 Thu Apr 03 18:53:54 CEST 2014 META-INF/LOCALFIL.SF
     866 Thu Apr 03 18:53:54 CEST 2014 META-INF/LOCALFIL.DSA
       0 Thu Apr 03 18:52:56 CEST 2014 META-INF/
smk 23121 Fri Dec 16 16:58:00 CET 2011 s:/verz/localfile-quellcode.java
  X.509, CN=Mein Name, C=de (localfile)
  [certificate is valid from 02.04.14 12:28 to 30.03.24 11:28]
s = signature was verified
m = entry is listed in manifest
k = at least one certificate was found in keystore
i = at least one certificate was found in identity scope

jar verified.

Warning:
This jar contains signatures that does not include a timestamp. Without a timestamp, users may not be able to validate this jar after the signer certificate’s expiration date (2024-03-30) or after any future revocation date.

Der Aufruf war:

keytool -selfcert -alias localfile -dname "cn=Mein Name, c=de" -keystore s:\verz\localfile_keystore.key

Was ich überhaupt nicht verstehe ist, warum das Datum von gestern drin steht? Ich habe die Datei von gestern garantiert vorher gelöscht. Die localfile_keystore.key hat als Dateidatum auch das heutige Datum. Wieso steht im Zertifikat das gestrige?

Nein, leider garnichts.

L-ectron-X · 3. April 2014 um 12:17

Was passiert, wenn du den Alias änderst? Immer noch das verkehrte Datum? Und so wie es aussieht, hat das Zertifikat immernoch eine Gültigkeit von 10 Jahren.
Es wurde also offenbar kein neues angelegt.

fischauge · 4. April 2014 um 10:06

Nächster Versuch mit neuem Alias und ohne Parameter -validity:

C:\Program Files (x86)\Java\jdk1.7.0_51\bin>jarsigner -verify -verbose -certs s:\verz\localfile.jar
       0 Fri Apr 04 18:49:36 CEST 2014 META-INF/
      52 Fri Apr 04 18:49:36 CEST 2014 META-INF/MANIFEST.MF
   23121 Fri Dec 16 16:58:00 CET 2011 s:/verz/localfile-quellcode.java
s = signature was verified
m = entry is listed in manifest
k = at least one certificate was found in keystore
i = at least one certificate was found in identity scope

jar is unsigned. (signatures missing or not parsable)

Dann wird nichts signiert.

Und noch ein Versuch wieder mit neuem Alias und mit -validity 365 (ich wollte mal nicht direkt 10 Jahre nehmen):

C:\Program Files (x86)\Java\jdk1.7.0_51\bin>jarsigner -verify -verbose -certs s:\verz\localfile.jar
       0 Fri Apr 04 18:54:28 CEST 2014 META-INF/
      52 Fri Apr 04 18:54:28 CEST 2014 META-INF/MANIFEST.MF
   23121 Fri Dec 16 16:58:00 CET 2011 s:/verz/localfile-quellcode.java
s = signature was verified
m = entry is listed in manifest
k = at least one certificate was found in keystore
i = at least one certificate was found in identity scope

jar is unsigned. (signatures missing or not parsable)

Wieder nichts signiert.

Und dritter Versuch des heutigen Abends wieder mit neuem Alias und wieder 10 Jahren:

C:\Program Files (x86)\Java\jdk1.7.0_51\bin>jarsigner -verify -verbose -certs s:\verz\localfile.jar
       0 Fri Apr 04 18:57:42 CEST 2014 META-INF/
      52 Fri Apr 04 18:57:42 CEST 2014 META-INF/MANIFEST.MF
   23121 Fri Dec 16 16:58:00 CET 2011 s:/verz/localfile-quellcode.java
s = signature was verified
m = entry is listed in manifest
k = at least one certificate was found in keystore
i = at least one certificate was found in identity scope

jar is unsigned. (signatures missing or not parsable)

Wieder nichts.
Kann es sein, dass mein PC jetzt garnichts mehr signiert?

Hier ist die Liste, was ich immer machen:

c:
cd "\Program Files (x86)\Java\jdk1.7.0_51\bin"
alte localfile.jar und localfile_keystore.key löschen, soweit noch vorhanden
jar cfmv s:\verz\localfile.jar s:\verz\manifest.mf s:\verz\localfile-quellcode.java
keytool -genkey -alias l1file -dname "cn=Projektname, c=de" -keystore s:\verz\localfile_keystore.key -validity 3650
	Kennwort: meinkennwort
keytool -selfcert -alias l1file -dname "cn=Projektname, c=de" -keystore s:\verz\localfile_keystore.key -validity 3650
	Keystore-Kennwort: meinkennwort
jarsigner s:\verz\localfile.jar l1file
	Passphrase: meinkennwort
jarsigner -verify -verbose -certs s:\verz\localfile.jar

Und hier mal beispielshaft der Ablauf des letzten Versuchs:

C:\Program Files (x86)\Java\jdk1.7.0_51\bin>jar cfmv s:\verz\localfile.jar s:\verz\manifest.mf s:\verz\localfile-quellcode.java
Manifest wurde hinzugef³gt
s:/verz/localfile-quellcode.java wird hinzugef³gt(ein = 23121) (aus = 4497)(80 % verkleinert)

C:\Program Files (x86)\Java\jdk1.7.0_51\bin>keytool -genkey -alias l1file -dname „cn=Projektname, c=de“ -keystore s:\verz\localfile_keystore.key -validity 3650
Keystore-Kennwort eingeben:
Neues Kennwort erneut eingeben:
Schl³sselkennwort f³r eingeben
(RETURN, wenn identisch mit Keystore-Kennwort):

C:\Program Files (x86)\Java\jdk1.7.0_51\bin>keytool -selfcert -alias l1file -dname „cn=Projektname, c=de“ -keystore s:\verz\localfile_keystore.key -validity 3650
Keystore-Kennwort eingeben:

C:\Program Files (x86)\Java\jdk1.7.0_51\bin>jarsigner s:\verz\localfile.jar l1file
Enter Passphrase for keystore:
jarsigner: Certificate chain not found for: l1file. l1file must reference a valid KeyStore key entry containing a private key and corresponding public key certificate chain.

C:\Program Files (x86)\Java\jdk1.7.0_51\bin>jarsigner -verify -verbose -certs s:\verz\localfile.jar
       0 Fri Apr 04 18:57:42 CEST 2014 META-INF/
      52 Fri Apr 04 18:57:42 CEST 2014 META-INF/MANIFEST.MF
   23121 Fri Dec 16 16:58:00 CET 2011 s:/verz/localfile-quellcode.java
s = signature was verified
m = entry is listed in manifest
k = at least one certificate was found in keystore
i = at least one certificate was found in identity scope

jar is unsigned. (signatures missing or not parsable)

Hat die Meldung ```jarsigner: Certificate chain not found for: l1file. l1file must reference a valid KeyStore key entry containing a private key and corresponding public key certificate chain.

Fällt ansonsten etwas im Ablauf auf? Mache ich was falsch?

L-ectron-X · 4. April 2014 um 12:47

C:\Program Files (x86)\Java\jdk1.7.0_51\bin>jar cfmv s:\verz\localfile.jar s:\verz\manifest.mf s:\verz\localfile-quellcode.java

Naja, du fügst eine Java-Datei in dein Jar-File. Da gehören doch kompilierte Class-Dateien hinein, wenn man damit etwas machen möchte…

fischauge · 4. April 2014 um 23:44

OK, wusste ich nicht. Aber damit entsteht ein neues Problem.
Der Ablauf:

[ul]
[li]c:
[/li][li]cd „\Program Files (x86)\Java\jdk1.7.0_51\bin“
[/li][li]alte localfile.jar und localfile_keystore.key löschen, soweit noch vorhanden
[/li][li]jar cfmv s:\verz\localfile.jar s:\verz\manifest.mf s:\verz\localfile-kompiliert.class
[/li][li]keytool -genkey -alias localfiletool -dname „cn=Testname, c=de“ -keystore s:\verz\localfile_keystore.key
[/li][li] Kennwort: test2014
[/li][li]keytool -selfcert -alias localfiletool -dname „cn=Testname, c=de“ -keystore s:\verz\localfile_keystore.key
[/li][li] Keystore-Kennwort: test2014
[/li][li]jarsigner s:\verz\localfile.jar localfiletool
[/li][li] Passphrase: test2014
[/li][li]jarsigner -verify -verbose -certs s:\verz\localfile.jar
[/li][/ul]

Das Ergebnis:

C:\Program Files (x86)\Java\jdk1.7.0_51\bin>jar cfmv s:\verz\localfile.jar s:\verz\manifest.mf s:\verz\localfile-kompiliert.class
Manifest wurde hinzugef³gt
s:/verz/localfile-kompiliert.class wird hinzugef³gt(ein = 7527) (aus = 3954)(47 % verkleinert)

C:\Program Files (x86)\Java\jdk1.7.0_51\bin>keytool -genkey -alias localfiletool -dname „cn=Testname, c=de“ -keystore s:\verz\localfile_keystore.key
Keystore-Kennwort eingeben:
Neues Kennwort erneut eingeben:
Schl³sselkennwort f³r eingeben
(RETURN, wenn identisch mit Keystore-Kennwort):

C:\Program Files (x86)\Java\jdk1.7.0_51\bin>keytool -selfcert -alias localfiletool -dname „cn=Testname, c=de“ -keystore s:\verz\localfile_keystore.key
Keystore-Kennwort eingeben:

C:\Program Files (x86)\Java\jdk1.7.0_51\bin>jarsigner s:\verz\localfile.jar localfiletool
Enter Passphrase for keystore:
jarsigner error: java.lang.RuntimeException: keystore load: Keystore was tampered with, or password was incorrect

C:\Program Files (x86)\Java\jdk1.7.0_51\bin>jarsigner -verify -verbose -certs s:\verz\localfile.jar
       0 Sat Apr 05 08:30:20 CEST 2014 META-INF/
      52 Sat Apr 05 08:30:20 CEST 2014 META-INF/MANIFEST.MF
    7527 Wed Dec 14 15:09:26 CET 2011 s:/verz/localfile-kompiliert.class
s = signature was verified
m = entry is listed in manifest
k = at least one certificate was found in keystore
i = at least one certificate was found in identity scope

jar is unsigned. (signatures missing or not parsable)

Das Passwort lautet test2014. Schlüsselkennwort gleich (Enter gedrückt). Hab es dreimal von vorne jedesmal mit anderem Alias und anderem validity (mal 1 Jahr, mal 10 Jahre und am Schluss ohne) probiert, das Passwort ist nicht falsch, ich verwette meine Hände drauf. Numlock und Capslock sind es nicht, beides überprüft.

So sieht übrigens die Manifest Datei aus. Daran kann es aber nicht liegen, oder?

Manifest-Version: 1.0
Created-by: Testname

(am Ende ist eine Leerzeile)

Ich finde diese Sache hier gerade unglaublich undurchsichtig und seltsam. Ist das normal? Java verstärkt die Sicherheitsvorkehrungen, und gibt einem dann keine leicht bedienbare Möglichkeit, diese für vertrauenswürdige Inhalte zu bestehen/überwinden? Das kommt mir äußerst spanisch vor :verzweifel:

L-ectron-X · 5. April 2014 um 06:58

Wenn das alles ist, was in der Manifest-Datei steht, ist das Jar-File definitiv nicht signiert. In einem Manifest einer signirten Jar-Datei sind die Klassennamen mit ihren Schlüsseln aufgelistet.

Hast du mal die Batchdatei aus dem Wikibeitrag auf dein System kopiert, angepasst und ausprobiert? Die sollte funktionieren.
Ich habe bisher noch nicht von diesem Fehler mit dem fehlerhaften Keystore-Passwort gehört. Sehe das bei dir zum ersten Mal.

Mal noch ein Schuss ins Blaue:
[ul]
[li]Du kannst auch mal probieren, den Alias nicht länger als 8 Zeichen werden zu lassen.
[/li][li]Vielleicht kannst du auch nicht signieren, weil du den Schlüssel und das Zetrtifikat in ein von dir vorgegebenes Verzeichnis speicherst.
[/li]Es könnte sein, dass beim Signieren dann in einem anderen Verzeichnis (Benutzer-Verzeichnis) nach dem Keystore gesucht wird.
[/ul]

fischauge · 5. April 2014 um 08:50

Hmm, wie geht das denn?

Ja klar. Der Ablauf ist aus deiner Batchdatei.
Und die Manifest besteht dort auch nur aus zwei Zeilen:
echo Manifest-Version: 1.0>manifest.mf
echo Created-by: SignTool by L-ectron-X - byte-welt.net>>manifest.mf
und am Ende die Leerzeile
Da steht

Anpassen, wenn eine Applikation statt eines Applets signiert werden soll!

Also bleiben nur zwei Zeilen für die manifest Datei.

Sehe ich auch zum ersten mal seit ich in das JAR nicht die Quellcode Datei sondern die class Datei packe.

Hatte ich bei den zahlreichen Versuchen auch schon dabei.

[QUOTE=L-ectron-X;91303]Vielleicht kannst du auch nicht signieren, weil du den Schlüssel und das Zetrtifikat in ein von dir vorgegebenes Verzeichnis speicherst.
Es könnte sein, dass beim Signieren dann in einem anderen Verzeichnis (Benutzer-Verzeichnis) nach dem Keystore gesucht wird.[/QUOTE]
Das Signieren an sich klappte ja, als ich noch die Quelldatei verwendet habe anstatt der class Datei. Siehe Beiträge #9 und #11

Was muss ich denn in die Manifest Datei reinschreiben? Das scheint mir dann doch vielleicht eine wahrscheinlichere Ursache für das Problem zu sein.

*** Edit ***

Wenn ich den jarsigner Aufruf so abändere jarsigner -keystore s:\verz\localfile_keystore.key -storepass test2014 s:\verz\localfile.jar lf funktioniert das Signieren wieder und das Ergebnis sieht so aus:

C:\Program Files (x86)\Java\jdk1.7.0_51\bin>jarsigner -keystore s:\verz\localfile_keystore.key -storepass test2014 s:\verz\localfile.jar lf
jar signed.

Warning:
The signer certificate will expire within six months.
No -tsa or -tsacert is provided and this jar is not timestamped. Without a timestamp, users may not be able to validate this jar after the signer certificate’s expiration date (2014-07-04) or after any future revocation date.

C:\Program Files (x86)\Java\jdk1.7.0_51\bin>jarsigner -verify -verbose -certs s:\verz\localfile.jar

s 153 Sat Apr 05 17:35:46 CEST 2014 META-INF/MANIFEST.MF
  X.509, CN=Testname, C=de
  [certificate will expire on 04.07.14 17:32]
  [CertPath not validated: Path does not chain with any of the trust anchors]

     336 Sat Apr 05 17:35:48 CEST 2014 META-INF/LF.SF
     849 Sat Apr 05 17:35:48 CEST 2014 META-INF/LF.DSA
       0 Sat Apr 05 17:32:18 CEST 2014 META-INF/
sm 7527 Wed Dec 14 15:09:26 CET 2011 s:/verz/localfile-kompiliert.class
  X.509, CN=Testname, C=de
  [certificate will expire on 04.07.14 17:32]
  [CertPath not validated: Path does not chain with any of the trust anchors]
s = signature was verified
m = entry is listed in manifest
k = at least one certificate was found in keystore
i = at least one certificate was found in identity scope

jar verified.

Warning:
This jar contains entries whose certificate chain is not validated.
This jar contains entries whose signer certificate will expire within six months.
This jar contains signatures that does not include a timestamp. Without a timestamp, users may not be able to validate this
jar after the signer certificate’s expiration date (2014-07-04) or after any future revocation date.

C:\Program Files (x86)\Java\jdk1.7.0_51\bin>

ABER: Der Browser sucht dann wieder eine /java/localclass/jar.class anstatt eine /java/localfile.jar und es kommt nach wie vor das Popup, dass die Anwendung nicht signiert ist. Damit bin ich also wieder so weit wie in Beitrag #5
Da hoffe ich jetzt, vielleicht mit der Manifest Datei eine Besserung zu bekommen. Aber ich weiß nicht, was da rein muss. Hab jetzt 3 verschiedene Anleitungen dazu gelesen aber ich weiß es immer noch nicht. Ich kann sämtliche Beispiele und Anweisungen aus den Tut’s nicht auf meinen Fall übertragen, weil ich auch die Begriffe nicht kenne.
Dazu bitte ich nochmal konkret um Hilfe und freue mich auf jeden Hinweis.

L-ectron-X · 5. April 2014 um 09:05

Da muss nichts weiter in die Manifest-Datei. Der Rest wird beim Signieren automatisch darin abgelegt.
Wenn du in dein nun signiertes Jar-File hineinschaust, sollte die Manifest-Datei nun anders aussehen.

Zeige mal noch den HTML-Tag, mit dem du dein Applet einbindest.
Lies dazu auch noch mal im Wiki: http://wiki.byte-welt.net/wiki/Einbinden_von_Applets_in_HTML-Dateien

fischauge · 5. April 2014 um 09:49

[QUOTE=L-ectron-X]Da muss nichts weiter in die Manifest-Datei. Der Rest wird beim Signieren automatisch darin abgelegt.
Wenn du in dein nun signiertes Jar-File hineinschaust, sollte die Manifest-Datei nun anders aussehen.[/quote]
Stimmt.

Den Aufruf hab ich mal gem. deines Links angepaßt:

<object codebase="../java" archive="localfile.jar" classid="java:localfile.class" codetype="application/java-vm" width="1" height="1">

Bin damit auch ein ganz kleines Stück weiter gekommen. Der Browser und Java finden jetzt das Applet auf dem Webserver, es kommen zwei Popups aber trotz deren Bestätigung startet das Applet seine Arbeit nicht.

Die Javakonsole bleibt leer.

Mein neuer Ablauf:
[ul]
[li]c:
[/li][li]cd „\Program Files (x86)\Java\jdk1.7.0_51\bin“
[/li][li]alte localfile.jar und localfile_keystore.key löschen, soweit noch vorhanden
[/li][li]jar cfmv s:\verz\localfile.jar s:\verz\manifest.mf s:\verz\localfile.class
[/li][li]jar ufm s:\verz\localfile.jar s:\verz\addpermissions.txt (die Zeile ist neu)
[/li][li]keytool -genkey -alias localfile -dname „cn=Testname, c=de“ -keystore s:\verz\localfile_keystore.key
[/li][li] Kennwort: test2014
[/li][li]keytool -selfcert -alias localfile -dname „cn=Testname, c=de“ -keystore s:\verz\localfile_keystore.key
[/li][li] Keystore-Kennwort: test2014
[/li][li]jarsigner -keystore s:\verz\localfile_keystore.key -storepass test2014 s:\verz\localfile.jar localfile
[/li][li]jarsigner -verify -verbose -certs s:\verz\localfile.jar
[/li][/ul]

Die neue Datei addpermissions.txt:

Permissions: all-permissions
Codebase: http ://www.meinedomain.de/java
Application-Name: localfile

Das mit der Permissions Datei habe ich hier gefunden: java - How do I fix "missing Codebase, Permissions, and Application-Name manifest attribute" in my JNLP app? - Stack Overflow

Ergebnis:

C:\Program Files (x86)\Java\jdk1.7.0_51\bin>jarsigner -verify -verbose -certs s:\verz\localfile.jar

s 234 Sat Apr 05 18:36:10 CEST 2014 META-INF/MANIFEST.MF
  X.509, CN=Testname, C=de
  [certificate will expire on 04.07.14 18:36]
  [CertPath not validated: Path does not chain with any of the trust anchors]

     325 Sat Apr 05 18:36:10 CEST 2014 META-INF/LOCALFIL.SF
     851 Sat Apr 05 18:36:10 CEST 2014 META-INF/LOCALFIL.DSA
       0 Sat Apr 05 18:35:30 CEST 2014 META-INF/
sm 7527 Wed Dec 14 15:09:26 CET 2011 s:/verz/localfile.class
  X.509, CN=Testname, C=de
  [certificate will expire on 04.07.14 18:36]
  [CertPath not validated: Path does not chain with any of the trust anchors]
s = signature was verified
m = entry is listed in manifest
k = at least one certificate was found in keystore
i = at least one certificate was found in identity scope

jar verified.

Warning:
This jar contains entries whose certificate chain is not validated.
This jar contains entries whose signer certificate will expire within six months.
This jar contains signatures that does not include a timestamp. Without a timestamp, users may not be able to validate this
jar after the signer certificate’s expiration date (2014-07-04) or after any future revocation date.

Mehrere Fragen:
[ul]
[li]Habe ich die Einbindung der Permissionsdatei im Ablauf richtig drin?
[/li][li]Wie kann ich im ersten Popup das Feld „Anbieter“ mit meinem Namen füllen?
[/li][li]Warum sagt das zweite Popup, dass es signierte und nicht signierte Anwendungen gibt?
[/li][li]Wieso startet das Applet nicht?
[/li][/ul]

L-ectron-X · 5. April 2014 um 10:18

[QUOTE=fischauge]
Mehrere Fragen:
[ul]
[li]Habe ich die Einbindung der Permissionsdatei im Ablauf richtig drin?[/li][li]Wie kann ich im ersten Popup das Feld “Anbieter” mit meinem Namen füllen?[/li][li]Warum sagt das zweite Popup, dass es signierte und nicht signierte Anwendungen gibt?[/li][li]Wieso startet das Applet nicht?[/li][/ul][/QUOTE]

Weiß nicht, ob es notwendig ist, dass man Permissions setzen muss. Wenn das Applet signiert ist, hat es automatisch Vollzugriff, es sei denn der Benutzer hat die Rechte anders eingestellt. (Systemeinstellungen -> Java)
Edit: Ja, das ist nicht optional, sondern notwendig. Und zwar im Applet-Tag bzw. Object-Tag in der HTML-Datei und im Manifest.
Gar nicht, es sei denn, du kaufst ein Zertifikat. Diese Option gibts nur noch für gekaufte Zertifikate, so weiß ich weiß.
Selbstsignierte Jar-Dateien sind eben von “Unbekannt”.
Keine Ahnung. Wie viele Klassen hast du denn in deinem Projekt? Es müssen alle signiert sein.
Hast du externe Jar-Dateien eingebunden? Die müssen auch signiert werden.
Das kann an den Sicherheitseinstellungen im System liegen. Gib dem Applet mal mehr Rechte. Warum braucht es erweiterte Rechte?