JRE7 Update 40 und Zertifikate

Diskutiere JRE7 Update 40 und Zertifikate im Software Forum Forum im Bereich Hardware & Software Forum; Hallo, ich habe da mal 'ne Frage. Ich habe hier 'ne Anwendung, die unter Java läuft. Aktuell unter JRE7 Update 40, zuvor unter Upate 25. Nun...
  • JRE7 Update 40 und Zertifikate Beitrag #1
BioaSharky

BioaSharky

Super-Moderator
Teammitglied
Dabei seit
25.01.1999
Beiträge
18.511
Reaktionspunkte
9
Hallo,

ich habe da mal 'ne Frage. Ich habe hier 'ne Anwendung, die unter Java läuft. Aktuell unter JRE7 Update 40, zuvor unter Upate 25.
Nun ist es ja eine der Änderungen in dem Update, dass man die Sicherheitseinstellung zu einer Anwendung, die nicht oder selbst signiert ist, nicht mehr mit Häkchen merken kann.

New Security Warnings for Unsigned and Self-Signed Applications

New warnings are added in the dialogs for Unsigned and Self-Signed applications.

From the dialogs for Unsigned and Self-Signed applets, "Remember this decision" option has been removed. In addition, the previously remembered decisions for self-signed and unsigned applets will be ignored.

Bis einschließlich Update 25 gab's diesen Haken: "Do not show this again ..."
http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/securityDialogs.html

Nun muss man bei jedem Start der Anwendung einen Haken setzen und ausführen drücken. (siehe Screenshot)

Wie in der weiteren Erklärung zu lesen (zweites Bild), weißt die Anwendung ja eine Signatur auf, die aber bei der aufgerufenen jnlp-Datei fehlt. Im Zertifikatsspeicher von Java ist das Zertifikat zu finden.

Was kann ich nun tun, damit die Anwender nicht immer bei jedem Start das Häkchen setzen müssen?
Von Software-Provider ist nichts zu erwarten, dort gibt's nicht mal eine Meldung.
 

Anhänge

  • Java_Meldung.jpg
    Java_Meldung.jpg
    68,3 KB · Aufrufe: 24
  • Java_Meldung_Signatur.jpg
    Java_Meldung_Signatur.jpg
    60,3 KB · Aufrufe: 16
  • Java_Zertifikate.jpg
    Java_Zertifikate.jpg
    48,2 KB · Aufrufe: 15
  • JRE7 Update 40 und Zertifikate Beitrag #2
Kalle-Klump

Kalle-Klump

Verdienter Ex-Admin
Dabei seit
21.05.2001
Beiträge
26.069
Reaktionspunkte
17
Startest Du über den Browser oder der Java-Anwendung selbst? Im Java Ordner findest Du javaws.exe, damit kannst Du Webfunktionen direkt aufrufen - javaws.exe http://xxyyzz.ko - damit bekomme ich keine Warnungen.
 
  • JRE7 Update 40 und Zertifikate Beitrag #3
BioaSharky

BioaSharky

Super-Moderator
Teammitglied
Dabei seit
25.01.1999
Beiträge
18.511
Reaktionspunkte
9
  • JRE7 Update 40 und Zertifikate Beitrag #4
Kalle-Klump

Kalle-Klump

Verdienter Ex-Admin
Dabei seit
21.05.2001
Beiträge
26.069
Reaktionspunkte
17
  • JRE7 Update 40 und Zertifikate Beitrag #5
BioaSharky

BioaSharky

Super-Moderator
Teammitglied
Dabei seit
25.01.1999
Beiträge
18.511
Reaktionspunkte
9
Das mag sein. Doch damit kannst Du mit Command-Line Optionen arbeiten. http://docs.oracle.com/javase/7/docs/technotes/tools/share/javaws.html <-- findest Du schon mal ein paar spezifische Optionen.

Habe dort keine CommandLine Run Option gefunden, welche die Sicherheitsmeldung betrifft.
Welche meinst du?

Denkbar wäre vielleicht auch ein Aufruf, der mit "< ja.txt" quasi die Bestätigung automatisch bekommt...?!

Wie soll das gehen? Habe auch dazu in der verlinkten Doku nichts gefunden.

Ich dachte auch eher daran, die Ursache zu bekämpfen, also, warum er die JNLP als unsigniert einstuft, obwohl ein Zertifikat da ist.
 
  • JRE7 Update 40 und Zertifikate Beitrag #6
Kalle-Klump

Kalle-Klump

Verdienter Ex-Admin
Dabei seit
21.05.2001
Beiträge
26.069
Reaktionspunkte
17
javaws.ex http:// < ja.txt
[wobei ja.txt eine Antwort enthält wie "J"]

Ich kenne keine fertige Lösung, da ich das Problem nicht nachstellen kann. Ich wollte nur Möglichkeiten aufzeigen.
 
  • JRE7 Update 40 und Zertifikate Beitrag #7
BioaSharky

BioaSharky

Super-Moderator
Teammitglied
Dabei seit
25.01.1999
Beiträge
18.511
Reaktionspunkte
9
javaws.ex http:// < ja.txt
[wobei ja.txt eine Antwort enthält wie "J"]
...

Nee, das funktioniert nicht, da ja keine Antwort in dem Sinne erwartet wird, sondern die Standard-Sicherheitswarnung angehakt und "Ausführen" geklickt werden muss.
 
  • JRE7 Update 40 und Zertifikate Beitrag #8
femi

femi

Super-Moderator
Teammitglied
Dabei seit
08.12.1998
Beiträge
6.886
Reaktionspunkte
3
Java Deployment Toolkit (click-to-play) wurde zu Ihrem Schutz gesperrt.

Warum wurde es gesperrt?The Java Deployment Toolkit plugin is known to be insecure and is unnecessary in most cases. Users should keep it disabled unless strictly necessary.Wer ist betroffen?All Firefox users who have this plugin installed.Was bedeutet das?Das problematische Add-on oder Plugin wird automatisch deaktiviert und ist dann nicht mehr benutzbar.
Wenn Mozilla Kenntnis von Add-ons, Plugins oder anderer Drittsoftware erhält, die ernsthaft die Sicherheit, Stabilität oder Leistung von Firefox beeinträchtigt und bestimmte Kriterien erfüllt, kann diese Software von der allgemeinen Benutzung ausgeschlossen werden. Weitere Informationen finden Sie in diesem Hilfeartikel.
Erst dachte ich, das nur der IE das jedes Mal einblendet, ist aber bei Firefox s. oben auch der Fall.
Wäre natürlich ideal, wenn man Seiten auf eine White-List legen könnte.

Einstellungen lassen sich in System-Steuerung/Java-Control-Panel/Erweitert vornehmen (hab's noch nicht probiert). Die Einstellungen in System-Steuerung/Java-Control-Panel/Sicherheit haben keinen Einfluss darauf.
 
Zuletzt bearbeitet:
  • JRE7 Update 40 und Zertifikate Beitrag #9
femi

femi

Super-Moderator
Teammitglied
Dabei seit
08.12.1998
Beiträge
6.886
Reaktionspunkte
3
... selbst wenn ich im Control Panel alles zulasse, kommt das Fenster immer noch :böse:
 
  • JRE7 Update 40 und Zertifikate Beitrag #10
FerFemNemBem

FerFemNemBem

Moderator
Teammitglied
Dabei seit
11.09.1999
Beiträge
4.494
Reaktionspunkte
0
Mahlzeit,

ich habe mir das mal angesehen... man kann bei javaws zwar D-Paramater an die VM mit -J uebergeben, da gibt es aber leider nichts, was die Meldung unterdruecken koennte.

Einziger Loesungsweg (momentan in meinen Augen). Lade Dir das jnlp und die dazugehoerigen jars herunter. In Deinem JDK findest Du das "keytool". Besorge Dir ein Zertifikat und signe die/das jar(s) neu mit Deinem Zertifikat. Anschliessend schiebst Du es bei Euch ins Intranet und laesst die Benutzer das von dort starten.

Problem ist: wenn der Hersteller an seiner Software was aendert, dann bekommt Ihr das nicht mit.

Gruss, FFNB.
 
  • JRE7 Update 40 und Zertifikate Beitrag #11
BioaSharky

BioaSharky

Super-Moderator
Teammitglied
Dabei seit
25.01.1999
Beiträge
18.511
Reaktionspunkte
9
Das Programm ist bei uns im eigenen Netz installiert, d.h. wir haben ein Installations-Paket, welches wir auf einem Tomcat6 mit PostgreSQL installiert haben. Der Hersteller liefert ja offensichtlich ein "eigenes" Zertifikat, welches bis 2017 gültig ist, nur die JNLP ist nicht damit signiert.
Außerdem stimmt irgendwas mit dem Manifest nicht. (siehe Hinweise: An Hersteller und Kunden)
Ich poste jetzt nochmal die Meldungen der aktuellen JRE7 Update 45 (seit heute).

PS: Mit der JRE7 U45 blockiert er dann auch die Verbindung zum Server. Nehme ich die runter und installiere wieder die JRE7 U40 kommt nur der Prompt, den ich anhaken kann und die Anwendung kann ausgeführt werden. Mit der JRE7 U25 kann ich den Sicherheitspromt, als "gemerkt" permanent verschwinden lassen.
 

Anhänge

  • Java_Meldung1.jpg
    Java_Meldung1.jpg
    82,5 KB · Aufrufe: 6
  • Java_Meldung2.jpg
    Java_Meldung2.jpg
    85 KB · Aufrufe: 6
  • Java_Meldung_Zertifikat.jpg
    Java_Meldung_Zertifikat.jpg
    62,6 KB · Aufrufe: 5
  • JRE7 Update 40 und Zertifikate Beitrag #12
FerFemNemBem

FerFemNemBem

Moderator
Teammitglied
Dabei seit
11.09.1999
Beiträge
4.494
Reaktionspunkte
0
Mahlzeit,

das sind doch aber sicher 2 verschiedene Dinge - oder? Was in Euerem Tomcat deployt ist, wird der "Server" sein, und ueber Webstart starten die Anwender eine Client-Anwendung, die dann darauf zugreift - oder?

Wenn das so ist, wozu dann ueberhaupt das Webstart-Zeugs? Dann verteile das jar auf die Clientrechner und lege einen Shortcut auf dem Desktop an. Damit sparst Du Dir das ganze Zertifikats und Sandbox-geraffel.

Ansonsten - Da Du ja die jars herunterladen und bei Euch im Intranet bereitstellen kannst - passe einfach das MANIFEST.MF-File an. So ein jar ist ja nur ein zip, und Du kannst dort mit jedem Packer alles rausholen, anpassen und wieder reinpacken.

Gruss, FFNB.
 
  • JRE7 Update 40 und Zertifikate Beitrag #13
BioaSharky

BioaSharky

Super-Moderator
Teammitglied
Dabei seit
25.01.1999
Beiträge
18.511
Reaktionspunkte
9
Ja, es gibt eine Serverkomponente und eine Client-Komponente.

Das ist nicht nur ein jar. Das ist die Distributed Version einer Suite einer Chemikalienverwaltung und -zulassung gemäß REACH-Verordnung. Wäre es die zugehörige Stand-alone Version, wäre das vielleicht gegangen, aber so?
Das mit dem Webstart ist auch deren Vorgehensweise, um auf den Clients die Applikation zu starten. Welche Dateien ich auf den Client übertragen müsste, um hier lokal die Anwendung zu starten, weiß ich gar nicht. Darüber gibt's keine Info, damit auch der Datenbankzugriff auf den Server funktioniert.
Auch nicht, was ich in welchem Manifest ändern müsste.
Ich habe jetzt mal mein Problem an den Hersteller, die ECHA, übermittelt.
http://de.wikipedia.org/wiki/IUCLID

Ich schau morgen mal, ob ich die Client-Komponente komplett getrennt irgendwie auch lokal "installiert" bekomme. In der Anleitung steht dazu nichts.
 
  • JRE7 Update 40 und Zertifikate Beitrag #14
FerFemNemBem

FerFemNemBem

Moderator
Teammitglied
Dabei seit
11.09.1999
Beiträge
4.494
Reaktionspunkte
0
Mahlzeit,

welche Dateien Du brauchst steht in der jnlp-Datei. Letztendlich, (grob gesagt) macht webstart auch nichts anderes, als die Dateien herunterzuladen und auf dem Rechner zu starten.

Die 1. Workaround-Vorgehensweise waere:
- jnlp-Datei herunterladen und im Editor ansehen
- alle darin enthaltenen resourcen (jars, bilder, dlls etc.) herunterladen
- ein Zertifikat besorgen
- die heruntergeladenen jars damit neu signieren
- die resourcen auf Euren Intranet-Server packen
- das jnlp-file so anpassen, dass die resourcen von Eurem Server und nicht mehr vom Anbieter geladen werden.
- das jnlp-file ins intranet packen und den Leuten sagen, dass sie die Anwendung von dort starten sollen.

Die 2. Workaround-Vorgehensweise waere:
- jnlp-Datei herunterladen und im Editor ansehen
- alle darin enthaltenen resourcen (jars, bilder, dlls etc.) herunterladen
- die resourcen auf die Client-Rechner packen
- eine batch o.ä. erstellen, die das jar startet (welches jar wie gestartet werden muss, steht auch wieder im jnlp-file)

Die richtige Vorgehnsweise: dem Hersteller sagen, dass er seinen Kram fixen soll. Weil: demnaechst wird Oracle die Ausfuehrung von fehlerhaft zertifizierten Anwendungen komplett unterbinden.

Gruss, FFNB.
 
  • JRE7 Update 40 und Zertifikate Beitrag #15
BioaSharky

BioaSharky

Super-Moderator
Teammitglied
Dabei seit
25.01.1999
Beiträge
18.511
Reaktionspunkte
9
Mahlzeit,

welche Dateien Du brauchst steht in der jnlp-Datei. Letztendlich, (grob gesagt) macht webstart auch nichts anderes, als die Dateien herunterzuladen und auf dem Rechner zu starten.

Die 1. Workaround-Vorgehensweise waere:
- jnlp-Datei herunterladen und im Editor ansehen
- alle darin enthaltenen resourcen (jars, bilder, dlls etc.) herunterladen
- ein Zertifikat besorgen
- die heruntergeladenen jars damit neu signieren
- die resourcen auf Euren Intranet-Server packen
- das jnlp-file so anpassen, dass die resourcen von Eurem Server und nicht mehr vom Anbieter geladen werden.
- das jnlp-file ins intranet packen und den Leuten sagen, dass sie die Anwendung von dort starten sollen.

Die JNLP wird schon lokal gestartet, die "Ressourcen" liegen alle bei uns im LAN, da wird nichts vom Anbieter geladen. Die JNLP liegt z.B. bei mir unter C:\IUCLID
Dazu müsste ich ja aber für ein Zertifikat sorgen - kostet das nicht?

Die 2. Workaround-Vorgehensweise waere:
- jnlp-Datei herunterladen und im Editor ansehen
- alle darin enthaltenen resourcen (jars, bilder, dlls etc.) herunterladen
- die resourcen auf die Client-Rechner packen
- eine batch o.ä. erstellen, die das jar startet (welches jar wie gestartet werden muss, steht auch wieder im jnlp-file)

Der Client könnte sogar ein ganzer eigener Ordner sein. Wie starte ich die .jar dann in einer Batch?
Die zu startende sollte diese sein, oder? (main=true)

Code:
        <!-- Define also needed jar files -->
        <jar href="i5client/jars/activation.jar" main="false"/>
<jar href="i5client/jars/asm.jar" main="false"/>
<jar href="i5client/jars/balloontip.jar" main="false"/>
<jar href="i5client/jars/binding.jar" main="false"/>
<jar href="i5client/jars/browserlauncher2.jar" main="false"/>
<jar href="i5client/jars/cglib-2.1.3.jar" main="false"/>
<jar href="i5client/jars/commons-beanutils.jar" main="false"/>
<jar href="i5client/jars/commons-codec.jar" main="false"/>
<jar href="i5client/jars/commons-collections.jar" main="false"/>
<jar href="i5client/jars/commons-httpclient.jar" main="false"/>
<jar href="i5client/jars/commons-lang.jar" main="false"/>
<jar href="i5client/jars/commons-logging.jar" main="false"/>
<jar href="i5client/jars/forms.jar" main="false"/>
<jar href="i5client/jars/glazedlists.jar" main="false"/>
<jar href="i5client/jars/hibernate3.jar" main="false"/>
<jar href="i5client/jars/HTMLEditorEnterprise.jar" main="false"/>
[B][COLOR="Red"]<jar href="i5client/jars/i5client.jar" main="true"/>[/COLOR][/B]
<jar href="i5client/jars/i5common.jar" main="false"/>
<jar href="i5client/jars/i5jpf.jar" main="false"/>
<jar href="i5client/jars/itext.jar" main="false"/>
<jar href="i5client/jars/iuclid5-jxpath-1.2.jar" main="false"/>
<jar href="i5client/jars/jaxen.jar" main="false"/>
<jar href="i5client/jars/jazzy.jar" main="false"/>
<jar href="i5client/jars/jcalendar.jar" main="false"/>
<jar href="i5client/jars/jdom.jar" main="false"/>
<jar href="i5client/jars/jh.jar" main="false"/>
<jar href="i5client/jars/jpf-boot.jar" main="false"/>
<jar href="i5client/jars/jpf.jar" main="false"/>
<jar href="i5client/jars/jxl.jar" main="false"/>
<jar href="i5client/jars/l2fprod-common-buttonbar.jar" main="false"/>
<jar href="i5client/jars/l2fprod-common-directorychooser.jar" main="false"/>
<jar href="i5client/jars/l2fprod-common-outlookbar.jar" main="false"/>
<jar href="i5client/jars/l2fprod-common-tasks.jar" main="false"/>
<jar href="i5client/jars/log4j.jar" main="false"/>
<jar href="i5client/jars/looks.jar" main="false"/>
<jar href="i5client/jars/myswing.jar" main="false"/>
<jar href="i5client/jars/opencsv-2.3.jar" main="false"/>
<jar href="i5client/jars/quartz.jar" main="false"/>
<jar href="i5client/jars/serializer.jar" main="false"/>
<jar href="i5client/jars/slf4j-api.jar" main="false"/>
<jar href="i5client/jars/slf4j-log4j12.jar" main="false"/>
<jar href="i5client/jars/swingx.jar" main="false"/>
<jar href="i5client/jars/validation.jar" main="false"/>
<jar href="i5client/jars/xalan.jar" main="false"/>
<jar href="i5client/jars/xercesImpl.jar" main="false"/>
<jar href="i5client/jars/xml-apis.jar" main="false"/>
<jar href="i5client/jars/xmlenc.jar" main="false"/>
<jar href="i5client/jars/xmlwriter.jar" main="false"/>

Die richtige Vorgehnsweise: dem Hersteller sagen, dass er seinen Kram fixen soll. Weil: demnaechst wird Oracle die Ausfuehrung von fehlerhaft zertifizierten Anwendungen komplett unterbinden.

Gruss, FFNB.

Das ist mir klar, deshalb habe ich ja den Anbieter informiert. Dass Oracle das bei zukünftigen Java-Engines unterbindet hatte ich ja geschrieben, mit der JRE7U45 bekomme ich schon trotz runterschrauben der Sicherheit und bestätigen der Sicherheitsmeldung keine Verbindung mehr.
 
  • JRE7 Update 40 und Zertifikate Beitrag #16
FerFemNemBem

FerFemNemBem

Moderator
Teammitglied
Dabei seit
11.09.1999
Beiträge
4.494
Reaktionspunkte
0
Mahlzeit,

also wenn Du den Client sowieso schon lokal rumliegen hast, dann verstehe ich nicht, warum man da webstart verwendet. Ein jar startest Du mormalerweise mit "java -jar i5client.jar".

Probier mal, was er dann sagt. Ggfs muss man sich noch einen Classpath zusammenbauen.

Gruss, FFNB.
 
  • JRE7 Update 40 und Zertifikate Beitrag #17
BioaSharky

BioaSharky

Super-Moderator
Teammitglied
Dabei seit
25.01.1999
Beiträge
18.511
Reaktionspunkte
9
Mahlzeit,

also wenn Du den Client sowieso schon lokal rumliegen hast, dann verstehe ich nicht, warum man da webstart verwendet.

Nee, der liegt nicht lokal. Lokal liegt NUR die JNLP. Der Client liegt derzeit auf einem unserer Server.
Und Webstart wird verwendet, weil das so in der Anleitung steht. Es liegen derzeit nur das JNLP und ein Icon lokal auf den 4 Clients. Die eigentliche Clientanwendung holen sich die dann über Webstart vom Server. Hat ja auch bis zur 1.7.25 super funktioniert.
So muss der Client eben auch nur einmal ein Update erfahren, wenn sich was ändert.


Ein jar startest Du mormalerweise mit "java -jar i5client.jar".
Probier mal, was er dann sagt. Ggfs muss man sich noch einen Classpath zusammenbauen.

Danke, werde ich probieren.
Habe jetzt ein Ticket bei der ECHA bekommen und sie wollen Dank Good Administrative Practice innerhalb von 15 Werktagen antworten. :fly:

[Edit]
Kommt folgende Meldung bei Aufruf. Ich habe das komplette IUCLID-Verzeichnis lokal kopiert.
 

Anhänge

  • Aufruf_i5client.jpg
    Aufruf_i5client.jpg
    29,5 KB · Aufrufe: 6
  • JRE7 Update 40 und Zertifikate Beitrag #18
FerFemNemBem

FerFemNemBem

Moderator
Teammitglied
Dabei seit
11.09.1999
Beiträge
4.494
Reaktionspunkte
0
Mahlzeit,

dann haben die in der "MANIFEST.MF" das "Main-Class:"-Attribut "vergessen". Aber auch das findet man in der jnlp-Datei. Schau mal, was hinter dem Attribut "application-desc main-class=" steht.

Beispiel: "<application-desc main-class=com.firma.programm.Hauptfenster/>"

Dann muss Dein Kommandozeilenaufruf so aussehen:

java -jar i5client.jar com.firma.programm.Hauptfenster

Hast Du ueberhaupt Interesse, da weiter dran "rumzubasteln" oder willst Du lieber auf den Fix warten?

Gruss, FFNB.
 
  • JRE7 Update 40 und Zertifikate Beitrag #19
BioaSharky

BioaSharky

Super-Moderator
Teammitglied
Dabei seit
25.01.1999
Beiträge
18.511
Reaktionspunkte
9
Mahlzeit,

dann haben die in der "MANIFEST.MF" das "Main-Class:"-Attribut "vergessen". Aber auch das findet man in der jnlp-Datei. Schau mal, was hinter dem Attribut "application-desc main-class=" steht.

Beispiel: "<application-desc main-class=com.firma.programm.Hauptfenster/>"

Dort steht
Code:
<application-desc main-class="eu.eca.iuclid.client.ClientLauncher"/>

Dann muss Dein Kommandozeilenaufruf so aussehen:

java -jar i5client.jar com.firma.programm.Hauptfenster

So sieht mein Kommandozeilenaufruf aus (siehe Anhang)
Wie erwähnt, ich habe nur das gesamte Verzeichnis auf den Client kopiert, keine Klassen "registriert" oder ähnlich.


Hast Du ueberhaupt Interesse, da weiter dran "rumzubasteln" oder willst Du lieber auf den Fix warten?

ich würde schon basteln, denn ob da letztendlich was kommt, steht in den Sternen.
 

Anhänge

  • Aufruf_i5client2.jpg
    Aufruf_i5client2.jpg
    33,7 KB · Aufrufe: 3
  • JRE7 Update 40 und Zertifikate Beitrag #20
FerFemNemBem

FerFemNemBem

Moderator
Teammitglied
Dabei seit
11.09.1999
Beiträge
4.494
Reaktionspunkte
0
Mahlzeit,

sorry, mein Fehler. Wenn man die Klasse angibt, darf man nicht "java -jar" aufrufen, sonst wird versucht das Manifest auszulesen. Der richtige Aufruf waere also:

java -cp i5client.jar eu.eca.iuclid.client.ClientLauncher

Jetzt muessen wir nur hoffen, dass im Manifest wenigstens der Classpath eingetragen ist, sonst muesstest Du noch saemtliche benoetigte jars (aus der jnlp) mit an den classpath haengen. Das wuerde dann so aussehen:

java -cp i5client.jar;asm.jar;balloontip.jar;[alle weiteren jars] eu.eca.iuclid.client.ClientLauncher

Gruss, FFNB.
 
Thema:

JRE7 Update 40 und Zertifikate

ANGEBOTE & SPONSOREN

https://www.mofapower.de/

Statistik des Forums

Themen
213.179
Beiträge
1.579.171
Mitglieder
55.876
Neuestes Mitglied
RamiroGarn
Oben