3
JNLP-Start scheitert wegen unsignierten Eintrags
Hallochen Gemeinde,
für den Remote-Zugriff auf die Konsole eines Hardwaregeräts per LAN wird über die Gerätewebseite eine jnlp-Datei gestartet. Mit der dadurch gestarteten Java-Anwendung kann dann die Konsole (Tastatur/Maus und Bildschirm) ferngesteuert werden. Der Aufruf (mittels IcedTea-Web unter Debian) hat bis vor kurzem noch funktioniert. Nunmehr scheitert dies mit der Fehlermeldung:
Um das Problem zu lösen, habe ich die üblichen im Internet diskutierten Einstellungen in Java angepasst (bzgl. MD5, TLS 1.0, Signierung prüfen) angepasst. Zugleich probierte ich anstelle von OpenJDK-11-jre noch direkt die Routine javaws der Linux-Versionen von Oracle 8u361, 8u11 und 8 aus. Dennoch bleibt dieser Fehler unbeirrt bestehen.
Unter Windows scheitert der bisherige Zugriff gleichsam wie unter Linux.
Die Gerätewebseite / Java-Anwendung ist in die Firmware des Hardwaregerätes integriert. Die aktuelle Version der Firmware, die auch installiert ist, stammt von Ende 2012.
Kennt jemand eine Lösungsmöglichkeit?
Könnte die Fehlermeldung darauf hindeuten, dass in der Firmware ein Zertifikat integriert ist, dessen Gültigkeit nunmehr abgelaufen ist (= etwas mehr als zehn Jahre)?
Vielen Dank im Voraus für Eure Antworten
HansDampf06
für den Remote-Zugriff auf die Konsole eines Hardwaregeräts per LAN wird über die Gerätewebseite eine jnlp-Datei gestartet. Mit der dadurch gestarteten Java-Anwendung kann dann die Konsole (Tastatur/Maus und Bildschirm) ferngesteuert werden. Der Aufruf (mittels IcedTea-Web unter Debian) hat bis vor kurzem noch funktioniert. Nunmehr scheitert dies mit der Fehlermeldung:
com.sun.deploy.net.JARSigningException: Unsignierter Eintrag gefunden in Ressource: http://[URL]/Java/release/JViewer.jar
at com.sun.javaws.security.SigningInfo.getCommonCodeSignersForJar(Unknown Source)
at com.sun.javaws.security.SigningInfo.check(Unknown Source)
at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedResourcesHelper(Unknown Source)
at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedResources(Unknown Source)
at com.sun.javaws.Launcher.prepareResources(Unknown Source)
at com.sun.javaws.Launcher.prepareAllResources(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.launch(Unknown Source)
at com.sun.javaws.Main.launchApp(Unknown Source)
at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
at com.sun.javaws.Main.access$000(Unknown Source)
at com.sun.javaws.Main$1.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)Um das Problem zu lösen, habe ich die üblichen im Internet diskutierten Einstellungen in Java angepasst (bzgl. MD5, TLS 1.0, Signierung prüfen) angepasst. Zugleich probierte ich anstelle von OpenJDK-11-jre noch direkt die Routine javaws der Linux-Versionen von Oracle 8u361, 8u11 und 8 aus. Dennoch bleibt dieser Fehler unbeirrt bestehen.
Unter Windows scheitert der bisherige Zugriff gleichsam wie unter Linux.
Die Gerätewebseite / Java-Anwendung ist in die Firmware des Hardwaregerätes integriert. Die aktuelle Version der Firmware, die auch installiert ist, stammt von Ende 2012.
Kennt jemand eine Lösungsmöglichkeit?
Könnte die Fehlermeldung darauf hindeuten, dass in der Firmware ein Zertifikat integriert ist, dessen Gültigkeit nunmehr abgelaufen ist (= etwas mehr als zehn Jahre)?
Vielen Dank im Voraus für Eure Antworten
HansDampf06
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 6440758951
Url: https://administrator.de/contentid/6440758951
Ausgedruckt am: 24.11.2024 um 20:11 Uhr
3 Kommentare
Neuester Kommentar
Moin,
Gruß,
Dani
Der Aufruf (mittels IcedTea-Web unter Debian) hat bis vor kurzem noch funktioniert.
was hat sich geändert?Nunmehr scheitert dies mit der Fehlermeldung:
Stell das System auf englisch um und poste anschließend nochmals die Fehlermeldung. Mit der englischen Meldung, wächst die Chance einen Treffer bei den Suchmaschinen zu landen.Gruß,
Dani
Moin,
es gibt in Abhängigkeit zur verwendeten Java Laufzeitumgebung ein Security-File.
https://mkyong.com/java/where-is-the-java-security-file/
Da kannst Du die Sicherheit weiter aufbrechen. Mach das aber mit Vorsicht.
Ich habe habe auch recht alte Schüsseln am Start und dafür noch ein Windows 10 1511 am Start, weil ich sogar teilweise noch Flash brauche.
VG
bdmvg
es gibt in Abhängigkeit zur verwendeten Java Laufzeitumgebung ein Security-File.
https://mkyong.com/java/where-is-the-java-security-file/
Da kannst Du die Sicherheit weiter aufbrechen. Mach das aber mit Vorsicht.
Ich habe habe auch recht alte Schüsseln am Start und dafür noch ein Windows 10 1511 am Start, weil ich sogar teilweise noch Flash brauche.
VG
bdmvg
... höchstwahrscheinlich geht es anderen gelegentlich auch so: Man sucht beharrlich nach der Lösung eines Problems, kann sie trotz intensiver Recherche nicht finden und fragt schließlich andere. Und während man sehnlichst auf die erbetene Hilfe wartet, rattert im Kopf die Analyse des Problems weiter. Man geht noch einmal alles, was man bisher probiert hat, durch und siehe da: Plötzlich hat man noch eine kleine Idee - und das war's!
Deshalb präsentiere ich die gerade selbst gefundene Lösung.
Im Rahmen des Probierens unterschiedlicher Einstellungen spielte unter anderem der Begriff "URL der Codebasis" eine gewisse Rolle. Ein vorerst nicht erfolgreicher Lösungsansatz war gewesen, die Gerätewebseite per HTTPS anzulaufen, was zuvor noch das Hochladen eines SSL-Zertifikats erforderte. Diesen Ansatz hatte ich wegen der mittlerweile nahezu ausschließlichen HTTPS-Nutzung im Webbereich gedanklich mit dem als Fehler monierten Fehlen einer Signatur in Verbindung gebracht. Dennoch wunderte ich mich, dass trotz des nunmehrigen HTTPS-Zugriffs bei den Fehlermeldungen immer noch die in der JNLP-Datei angegebene Codebasis nur auf HTTP lautete, ohne dem weiter nachzugehen. Die einfache HTTP-URL ist auch in der Fehlermeldung oben gegeben.
Nach dem Absetzen des Beitrags war ich mit etwas ganz ganz anderem beschäftigt. Und wie ich soeben nachschaute, ob es vielleicht eine erste Antwort geben könnte (es gab noch keine), trat mir das mehrfache "(Unknown Source)" nochmals ins Auge. Warum ist jetzt plötzlich eine Quelle unbekannt? Es ist doch noch alles an seinem bisherigen Platz?! Und dann auch noch eine fehlende Signatur?!
Damit lag der ganz kleine Schritt zur Lösung vor den Füßen: Einfach ein "s" ans "http" in der JNLP-Datei und schon funktioniert es wieder! Unmittelbar zuvor hatte ich mittels jcontrol in den erweiterten Einstellungen alles, was die Sicherheitsanforderungen aktiviert oder erhöht, deaktiviert.
Jedenfalls unter jre-8-linux-x64 und den Updates 11, 65, 66, 131, 202, 251, 271 und 281 von Oracle läuft es jetzt wieder wie bisher; die Updates 291 und 361 verweigern den Start der Java-Anwendung aus Sicherheitsgründen ("Exception: null : LaunchDesc:"). Alle diese Update-Varianten habe ich jetzt gleich noch heruntergeladen und getestet und mit dem Update 281 bin ich vorerst "maximal" am aktuellen JRE-Stand heran. Ob ich darüber hinaus noch Zeit in die Updates ab 291 stecken werde, ist noch offen.
Und weil es eine rein intern genutzte Geschichte ist, sind die mittels jcontrol deaktivierten Sicherheitseinstellungen ein durchaus tolerierbares "Scheunentor" - der Standard des auf das Gerät zugreifenden Clientcomputers läuft noch immer über OpenJDK-11-jre und IcedTea-Web aus den offiziellen Debian-Quellen. Dort sind alle sicherheitsrelevanten Änderungen nun wieder auf den "strengen" originalen Zustand zurückgesetzt.
Dessen ungeachtet vielen Dank für Eure zwischenzeitlichen Antworten!
Viele Grüße und eine gute Nacht
HansDampf06
Deshalb präsentiere ich die gerade selbst gefundene Lösung.
Im Rahmen des Probierens unterschiedlicher Einstellungen spielte unter anderem der Begriff "URL der Codebasis" eine gewisse Rolle. Ein vorerst nicht erfolgreicher Lösungsansatz war gewesen, die Gerätewebseite per HTTPS anzulaufen, was zuvor noch das Hochladen eines SSL-Zertifikats erforderte. Diesen Ansatz hatte ich wegen der mittlerweile nahezu ausschließlichen HTTPS-Nutzung im Webbereich gedanklich mit dem als Fehler monierten Fehlen einer Signatur in Verbindung gebracht. Dennoch wunderte ich mich, dass trotz des nunmehrigen HTTPS-Zugriffs bei den Fehlermeldungen immer noch die in der JNLP-Datei angegebene Codebasis nur auf HTTP lautete, ohne dem weiter nachzugehen. Die einfache HTTP-URL ist auch in der Fehlermeldung oben gegeben.
Nach dem Absetzen des Beitrags war ich mit etwas ganz ganz anderem beschäftigt. Und wie ich soeben nachschaute, ob es vielleicht eine erste Antwort geben könnte (es gab noch keine), trat mir das mehrfache "(Unknown Source)" nochmals ins Auge. Warum ist jetzt plötzlich eine Quelle unbekannt? Es ist doch noch alles an seinem bisherigen Platz?! Und dann auch noch eine fehlende Signatur?!
Damit lag der ganz kleine Schritt zur Lösung vor den Füßen: Einfach ein "s" ans "http" in der JNLP-Datei und schon funktioniert es wieder! Unmittelbar zuvor hatte ich mittels jcontrol in den erweiterten Einstellungen alles, was die Sicherheitsanforderungen aktiviert oder erhöht, deaktiviert.
Jedenfalls unter jre-8-linux-x64 und den Updates 11, 65, 66, 131, 202, 251, 271 und 281 von Oracle läuft es jetzt wieder wie bisher; die Updates 291 und 361 verweigern den Start der Java-Anwendung aus Sicherheitsgründen ("Exception: null : LaunchDesc:"). Alle diese Update-Varianten habe ich jetzt gleich noch heruntergeladen und getestet und mit dem Update 281 bin ich vorerst "maximal" am aktuellen JRE-Stand heran. Ob ich darüber hinaus noch Zeit in die Updates ab 291 stecken werde, ist noch offen.
Und weil es eine rein intern genutzte Geschichte ist, sind die mittels jcontrol deaktivierten Sicherheitseinstellungen ein durchaus tolerierbares "Scheunentor" - der Standard des auf das Gerät zugreifenden Clientcomputers läuft noch immer über OpenJDK-11-jre und IcedTea-Web aus den offiziellen Debian-Quellen. Dort sind alle sicherheitsrelevanten Änderungen nun wieder auf den "strengen" originalen Zustand zurückgesetzt.
Dessen ungeachtet vielen Dank für Eure zwischenzeitlichen Antworten!
Zitat von @Dani:
Wie die durchgetesteten Updateversionen von Oracle zeigen, werden sich die Sicherheitsanforderungen ganz offensichtlich im Rahmen eines regulären Updates von OpenJDK-11-jre / IcedTea-Web schlichtweg verschärft haben, so dass der Zugriff auf das Gerät regulär nicht mehr möglich ist. Jedenfalls hat es über diese regulären Updates hinaus keine Veränderungen in Bezug auf Java gegeben.Der Aufruf (mittels IcedTea-Web unter Debian) hat bis vor kurzem noch funktioniert.
was hat sich geändert?Zitat von @beidermachtvongreyscull:
es gibt in Abhängigkeit zur verwendeten Java Laufzeitumgebung ein Security-File.
https://mkyong.com/java/where-is-the-java-security-file/
Ja, das war einer der ersten Anlaufpunkte, der aber keine Wirkung zeigte. Bis zum Update 281 muss diese Datei gar nicht weiter angefasst werden. Es reicht aus, mittels jcontrol die individuellen User-Einstellungen vorzunehmen.es gibt in Abhängigkeit zur verwendeten Java Laufzeitumgebung ein Security-File.
https://mkyong.com/java/where-is-the-java-security-file/
Da kannst Du die Sicherheit weiter aufbrechen. Mach das aber mit Vorsicht.
Das ist selbstredend (s.o.). Die manuell installierte Oracle-jre-8u281-Umgebung hat nur diesen Anwendungsfall und wird in keine andere Anwendung integriert werden. Sie wird vielmehr wie eine Art gekapselte JRE-Umgebung nur für diesen Anwendungsfall verwendet werden. Deswegen beurteile ich die Sicherheitsrisiken in der aktuellen Situation als überschaubar. Eine Steigerung der Sicherheit wäre noch möglich, wenn ich solche Management-Sachen in die Debian-VM auf dem Client verschiebe, die nur bei Bedarf gestartet und verwendet wird. Der kleine Mehraufwand wäre akzeptabel.Ich habe habe auch recht alte Schüsseln am Start und dafür noch ein Windows 10 1511 am Start, weil ich sogar teilweise noch Flash brauche.
Tja, wir sollen halt "konsumieren" und daher sorgt die frühzeitige (Ver)Weigerung des/r Hersteller des weiteren Supports (Firmware etc.) dafür, dass ein nachhaltiger Technikeinsatz eine Reihe von Kopfständen erfordert. So datiert die Firmware in meinem Fall ein halbes Jahr vor meinem Erwerb der Hardware in der regulären Vertriebsphase; laut Geizhals wurde diese Hardware sogar noch Jahre später bepreist/angeboten. Und nimmt man dann die reguläre Nutzungszeit dazu, ist es eigentlich eine Frechheit, dass es keine nachfolgenden Aktualisierungen der Firmware gab. Daher freut es mich umso mehr, dass ich eine akzeptable Lösung für die weitere Nutzung gefunden habe, verbunden mit der Hoffnung, dass meine Lösung auch für andere hilfreich sein kann.Viele Grüße und eine gute Nacht
HansDampf06
