Hi, ich habe hier ein Gerät mit einer Java-Weboberfläche. Das Gerät ist seitens des Herstellers mittlerweile ausgelaufen. Zuvor hat der Hersteller noch ein Firmwarupdate rausgegeben, dass, zumindest für uns, einiges schlimmer gemacht hat. Jetzt ist leider das Zertifikat dieser Java-Anwendung abgelaufen und die Browser/Java weigert sich diese Anwendung auszuführen. Gibt es da eine Möglichkeit, dass man Java dazu bringt dieses eine Zertifikat mit dem Fingerprint 'sowieso' zu ignorieren? VG
Matthias S. schrieb: > Hi, > > ich habe hier ein Gerät mit einer Java-Weboberfläche. Das Gerät ist > seitens des Herstellers mittlerweile ausgelaufen. Zuvor hat der > Hersteller noch ein Firmwarupdate rausgegeben, dass, zumindest für uns, > einiges schlimmer gemacht hat. > Jetzt ist leider das Zertifikat dieser Java-Anwendung abgelaufen und die > Browser/Java weigert sich diese Anwendung auszuführen. > Gibt es da eine Möglichkeit, dass man Java dazu bringt dieses eine > Zertifikat mit dem Fingerprint 'sowieso' zu ignorieren? > > VG Kannst du das Datum zurückstellen? Ich finde es übrigens eine Frechheit, ein Gerät mit fixem Ablaufdatum zu verkaufen. Java ist also ein eindeutiges Signal für "nicht kaufen".
Juchuu schrieb: > Datum zurückstellen? Das kann auch mit Totalschaden enden. Ein Image vorher wäre nützlich! Matthias S. schrieb: > Zertifikat dieser Java-Anwendung abgelaufen Ob man die Abfrage überspringen könnte? Da sollte man mehr wissen oder besser den Hersteller kontaktieren was er für Müll geliefert hat!
Juchuu schrieb: > Ich finde es übrigens eine Frechheit, ein Gerät mit fixem Ablaufdatum zu > verkaufen. Ich fände es frech, gängige Sicherheits-Best-Practices zu ignorieren. Dass Zertifikate erneuert werden müssen ist absolut üblich. Blöd ist nur, wenn man das Zertifikat nicht selbst austauschen kann und es keine Updates mehr gibt. Mit Java hat das übrigens absolut gar nichts zu tun. Matthias S. schrieb: > Jetzt ist leider das Zertifikat dieser Java-Anwendung abgelaufen und die > Browser/Java weigert sich diese Anwendung auszuführen. Ist damit ein Java-Applet gemeint? Oder läuft nur der Server auf Java? Im letzteren Fall kannst du doch im Browser einfach eine Sicherheits-Ausnahme hinzufügen.
1) Nehme an das Zertifikat lässt sich nicht ändern? Das wäre am einfachsten... 2) Nach meienr Erfahrung (ggf. nicht vollständig) ist das tricky - ich kenne nur Möglichkeiten das im Code zu machen, hier unterscheiden sich die Methoden dann je nach Implementierung, der Jakarta Http Client ist anders als die Http Methoden im JDK. Ggf. kann man hier mit jad decompilieren und das anpassen aber könnte aufwendig sein. Konkretere Ideen habe ich mangels Informationen von Dir nicht...
Matthias S. schrieb: > ich habe hier ein Gerät mit einer Java-Weboberfläche. > Jetzt ist leider das Zertifikat dieser Java-Anwendung abgelaufen und die > Browser/Java weigert sich diese Anwendung auszuführen. Was ist das für eine "Java Weboberfläche"? läuft da ein Java basierter Webserver auf "dem Gerät", oder handelt es sich um eine clientseitig auszuführende Anwendung die über z.b. JNLP gestartet wird? Welches Zertifikat ist abgelaufen? das SSL- oder das Codesigning Zertifikat?
Habe genau das gleiche Problem Habe einen kleinen Intel-Server mit einer Remote Access Karte, deren Zertifikat abgelaufen ist. Nun kann ich mich zwar in der Weboberfläche anmelden und konfigurieren aber keine Remote Sitzung herstellen. Dazu kann ich jetzt nur noch VNC oder ähnliches verwenden. Leider kann ich damit auch nicht den Bootvorgang remote kontrollieren und muss am Server Monitor und Tastatur anschließen und mich in die Ecke setzen. Bei älteren Java Versionen konnte man noch jedesmal beim Start nach mehreren Abfragen das Starten der Remote Verbindung erlauben, das geht leider nicht mehr
Niklas G. schrieb: > Juchuu schrieb: >> Ich finde es übrigens eine Frechheit, ein Gerät mit fixem Ablaufdatum zu >> verkaufen. > > Ich fände es frech, gängige Sicherheits-Best-Practices zu ignorieren. > Dass Zertifikate erneuert werden müssen ist absolut üblich. Blöd ist > nur, wenn man das Zertifikat nicht selbst austauschen kann und es keine > Updates mehr gibt. Mit Java hat das übrigens absolut gar nichts zu tun. Naja, bei sowas wäre es halt schlau gewesen, die Zertifikats-Lebensdauer auf 30 oder 50 Jahre zu stellen...
Sven B. schrieb: > Naja, bei sowas wäre es halt schlau gewesen, die Zertifikats-Lebensdauer > auf 30 oder 50 Jahre zu stellen... Damit ein eventuell geklautes Zertifikat/Schlüssel auch schön lange benutzt werden kann? Da lieber dem Nutzer/Besitzer die Möglichkeit geben es auszutauschen, bzw. allgemein mehr an der Firmware zu arbeiten. Das würde sowieso bei vielen Wartungs-Aspekten helfen.
Thomas S. schrieb: > Zertifikat abgelaufen Digitale Demenz wird und in nächster Zeit noch zahlreiche Verluste bringen. Eine Dampfmaschine kann man auch nach 100 Jahren noch benutzen während ein Zertifikat die Benutzung schon nach kurzer Zeit im Interesse der "Sicherheit" (oder der Geldgier) verhindert. Eigentlich besteht das ZertifikatsUNwesen ja aus 2 Teilen dem Ablaufdatum und der Bereitsteller (der in 100 Jahren verschwunden oder in Insolvenz ist).
oszi40 schrieb: > Eigentlich besteht das ZertifikatsUNwesen ja aus 2 Teilen dem > Ablaufdatum und der Bereitsteller (der in 100 Jahren verschwunden oder > in Insolvenz ist). Über Zertifikate zu lästern ist Symptom-Bekämpfung. Das eigentliche Problem besteht darin, dass die Hersteller einen vom System aussperren und keine Änderungen erlauben (z.B. Erneuerung des Zertifikats und vieles mehr). Viele andere Probleme welche die spätere Nutzung verhindern könnten, könnte man mit offenen (offen != unsicher) Systemen lösen. Der Grund, warum das nicht gemacht wird, ist natürlich Misstrauen und Gier. oszi40 schrieb: > Eine Dampfmaschine kann man auch nach 100 Jahren noch benutzen Die kann bestimmt heute schon keiner mehr bedienen, warten und reparieren.
Niklas G. schrieb: > Sven B. schrieb: >> Naja, bei sowas wäre es halt schlau gewesen, die Zertifikats-Lebensdauer >> auf 30 oder 50 Jahre zu stellen... > > Damit ein eventuell geklautes Zertifikat/Schlüssel auch schön lange > benutzt werden kann? Da lieber dem Nutzer/Besitzer die Möglichkeit geben > es auszutauschen, bzw. allgemein mehr an der Firmware zu arbeiten. Das > würde sowieso bei vielen Wartungs-Aspekten helfen. Für was soll das denn in diesem Fall bitte missbraucht werden? Wenn die Oberfläche an dem Gerät angezeigt wird, auf dem die Anwendung sowieso gespeichert ist, bringt das Zertifikat ohnehin nicht viel. Und wenn die Sicherheit tatsächlich eine Rolle spielt, sollte zusätzlich eine CRL geprüft werden, statt sich nur auf die Ablaufdauer zu verlassen ...
:
Bearbeitet durch User
Sven B. schrieb: > Wenn die > Oberfläche an dem Gerät angezeigt wird, auf dem die Anwendung sowieso > gespeichert ist, bringt das Zertifikat ohnehin nicht viel. Wird sie? Wozu dann als Web-Oberfläche? Sven B. schrieb: > sollte zusätzlich > eine CRL geprüft werden Das wird der Browser des Client-Rechners wohl hoffentlich tun.
Niklas G. schrieb: > Sven B. schrieb: >> Wenn die >> Oberfläche an dem Gerät angezeigt wird, auf dem die Anwendung sowieso >> gespeichert ist, bringt das Zertifikat ohnehin nicht viel. > > Wird sie? Wozu dann als Web-Oberfläche? Weiß nicht. Klang so. Die Frage "wozu" sollte man bei Systemen mit Java-Web-Applets im Jahr 2019 vermutlich manchmal einfach nicht stellen.
Sven B. schrieb: > Weiß nicht. Klang so. Die Frage "wozu" sollte man bei Systemen mit > Java-Web-Applets im Jahr 2019 vermutlich manchmal einfach nicht stellen. Ha! Ich hatte es so verstanden, dass das Gerät am Netz hängt und man per PC&Browser auf die Web-Oberfläche zugreift. Je nachdem was da sonst noch so im Netz ist und wie kritisch das Gerät, wäre eine wirksame Verschlüsselung (inkl. Zertifikat) wichtig.
Hi, es handelt sich hierbei um ein Gerät zur Gebäudevisualisierung. Wir greifen über einen Webbrowser darauf zu und es beschwert sich die Java-Engine auf dem Rechner mit dem ich auf diese Weboberfläche zugreife, über das Zertifikat. Die Oberfläche wird also nicht auf dem Gerät angezeigt, sondern kann von überall her in unserem Netzwerk abgerufen werden. Ich sehe nicht sehr viele Chancen darin, das Zertifikat auszutauschen. Auch Datum zurückstellen wird keine Option sein. Die Oberfläche ist allerdings nur von intern zu erreichen. Und wenn das letzten Endes auf einen Registery-Hack oder so hinausläuft, den die IT auf einzelnen Rechner durchführen muss, ist da auch nicht allzu viel ausgehebelt. Prinzipiell wird halt diese Zertifikatsabfrage dazu gedacht sein, dass ich nicht irgendwelche dubiosen Java-Anwendungen von irgendwelchen noch dubioseren Seiten ausführen kann. Sinnig. Aber genauso, wie ich manuell irgendwelchen abgelaufenen oder nicht signierten (weil rein interne) SSL-Zertifikaten vertrauen kann, würde ich jetzt gerne diesem abgelaufenem Java-Zertifikat vertrauen. Ich hätte in der Gebäudeautomatisierung hier übrigens Geräte, die schlagen von der Altertümlichkeit dieses Mopped um Längen. Nicht umsonst halte ich hier einen WindowsXP-Rechner ohne Internetanschluss vor... VG
Naja, dann gehen wir mal pragmatisch vor: unter Linux gibt es Tools wie "faketime", die für einzelne Anwendungen die Systemzeit faken. Vielleicht kann man so etwas benutzen und mit dem Browser halt nur diese Anwendung aufrufen?
Sprichst du von einem Browser-Plugin oder einer eigenständigen Java-Anwendung (.jar)? Es gibt seit Java 7 eine Exception List im Java Control Panel, vielleicht lässt es sich damit schon lösen. Seit Java 8, Update 20 gibt es als Sicherheitseinstellungen nur noch "Hoch" und "Sehr hoch", vielleicht lässt es sich mit einer vorherigen Version ausführen. Siehe auch diese Infoseite: https://www.java.com/en/download/help/jcp_security.xml Alte Java-Versionen sollten aber nur in einer wirklich kontrollierten Inselumgebung genutzt werden, aber ich denke darüber seid ihr euch im Klaren.
:
Bearbeitet durch User
L. C. schrieb: > Sprichst du von einem Browser-Plugin oder einer eigenständigen > Java-Anwendung (.jar)? Keine eigenständige Anwendung. Ich habe da wirklich einen Link mit der IP des Gerätes. L. C. schrieb: > Es gibt seit Java 7 eine Exception List im Java Control Panel, > vielleicht lässt es sich damit schon lösen. Ich habe jetzt mal schnell in meinem heimischen Java 10.0.2 (Ablaufdatum 16.11.2018 - ups) nachgeguckt: Unter Sicherheit => Zertifikate verwalten kann man Zertifikate hinzufügen. Wären dass dann Zertifikate mit denen sich "mein Rechner" ausweist, oder könnte ich da z.B. dieses abgelaufene Zertifikat als "Vertrauenswürdige Zertifikate" hinzufügen und es würde dann wieder passen? Dann wäre aber die Frage, ob ich irgendwie an das Zertifikat rankomme. Den zum Import hätte das Control-Panel gerne eine Zertifikatsdatei...
Ich kenne das konkrete Tool nicht, aber normalerweise verwalten diese Tools CA-Zertifikate. Die Zertifikat-Infrastruktur ist typischerweise (bei x509) ein Baum, bei der die tatsächlichen Zertifikate von einer CA signiert werden. Du kannst also da normalerweise einstellen, welchen CAs du traust, aber abgelaufene Zertifikate sind immer ungültig.
Sven B. schrieb: > aber abgelaufene Zertifikate sind immer ungültig. Kommt etwas auf SW-Stand und Browser an. Manchmal erscheint auch die böse Frage:"Wollen Sie trotzem?" Dann macht man evtl. ein Scheunentor auf.
Matthias S. schrieb: > Hi, > es handelt sich hierbei um ein Gerät zur Gebäudevisualisierung. Wir > greifen über einen Webbrowser darauf zu und es beschwert sich die > Java-Engine auf dem Rechner mit dem ich auf diese Weboberfläche > zugreife, über das Zertifikat. > Die Oberfläche wird also nicht auf dem Gerät angezeigt, sondern kann von > überall her in unserem Netzwerk abgerufen werden. Das minimale derzeit von Firefox unterstützte Security Protokoll ist TLS Version 1.0. Wenn das Gerät nur SSL 3.0 oder älter bietet, dann kannst du in Firefox das minimale Security Protokoll auf SSL 3.0 herabsetzen: http://kb.mozillazine.org/Security.tls.version.*#Possible_values_and_their_effects Für das abgelaufene Zertifikat kannst du dann noch eine Ausnahme einrichten. Wichtig ist erst einmal, dass der Browser das gleiche Security Protokoll spricht, wie das Gerät mit dem Javadienst. Falls das geholfen hat, dann beachte bitte, dass es für das normale Surfen nicht empfehlenswert ist, die Protokollversion des Browsers herabzusetzen. In dem Fall wäre es also ratsam, zum normalen Surfen bspw. eine zweite Browserinstanz mit den sichereren Standardeinstellungen zu verwenden und für dieses eine Gerät einen extra Browser mit dem niedrigeren Sicherheitsprotokoll. Das minimale Security Protokoll dürfte mittelfristig in Firefox sogar auf TLS Version 1.1 heraufgesetzt werden, da TLS 1.0 auch nicht mehr so sicher ist, wie man gerne hätte. Das Problem liegt hier übrigens nicht unbedingt am Gerät. Die Gewährleistung beträgt ja nur 2 Jahre. Beim Browser liegt sie allerdings auch nicht, da man mit dem natürlich auch sich sicher im Internet bewegen können möchte, auch wenn dieser technisch durch diese Einstellung durchsetzt, dass es nicht mehr geht.
Kurze Rückmeldung: Ich habe das Update eingespielt. Das hat damals mein Vorgänger ausprobiert und dann wieder gedowngradet, weil irgendwas nicht funktioniert hat. Entweder gibt es da mittlerweile schon ein neueres Update, oder mir ist der Fehler noch nicht aufgefallen. Auf jeden Fall hat aber dieses Update das Zertifikat wohl auch aktualisiert und wir können wieder normal darauf zugreifen. Eine kurze Frage hätte ich da noch: Kann ich mir irgendwo das Zertifikat anzeigen lassen, damit nachgucken kann, wann das aktuelle Zertifikat abläuft? VG
Matthias S. schrieb: > Kann ich mir irgendwo das Zertifikat anzeigen lassen, damit nachgucken > kann, wann das aktuelle Zertifikat abläuft? Firefox: Tools -> Page Info -> Ssecurity IE: File -> Properties -> Certificates
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.